axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ruwan.lin...@gmail.com
Subject Re: [Axis2] Displaying the Service Information on the GET request
Date Sat, 15 Dec 2007 15:18:40 GMT
Hi Chinthaka,

If you look at my proposal carefully there I have stated about a
configuration point on which the behavior of the GET request over the
service path will be determined from one of the wsdl or service path.
May be we can add this (the feature you described which is already
supported by XFire) also as an option to that configuration so that we
can support that.

In effect that configuration specify the behavior of the service path either as
* the service wsdl
* the service information
* or the operation which is exposed at the service path (obviously
this operation should not expect any parameters)

I also think this is a good feature to implement.

Thanks,
Ruwan

On 12/14/07, Eran Chinthaka <chinthaka@opensource.lk> wrote:
> Hi Ruwan,
>
> This is certainly a good feature if you can add. But I can remember
> XFire was doing something similar to this. This is how it worked, IIRC.
>
> If you have a service (say Foo) with only one operation (bar) , then
> when you invoke the service (without the operation name), then that
> request goes to the only operation. Meaning both
> http://<host>:<port>/axis2/services/Foo and
> http://<host>:<port>/axis2/services/Foo/bar are the same.
>
> If this bar operation adheres to IRI style (please check IRI style in
> WSDL 2.0 spec), then doing a GET operation on this service should invoke
> bar operation in a RESTful manner (oops, POX over HTTP).
>
> So if you implement GET request to return the service description, then
> there might be conflict. If you just invoke the operation with
> http://<host>:<port>/axis2/services/Foo, then axis2 will send the famous
> operation not found error. I know the above feature is not implemented.
> , but that is something cool I saw in XFire.
>
> This is just a suggestion and noway this should be considered as an
> objection to your initial proposal. A small disclaimer ;)
>
> Thanks,
> Chinthaka
>
> Ruwan Linton wrote:
> > Hi axis2 folks,
> >
> > We (synapse-dev) is in the process of doing some refactoring on the GET
> > request processors. For the moment we do provide a service information
> > html page on doing a GET request on the service path and discussing to
> > add a ?info filter for that and keep the original service path for any
> > other thing (may be we can provide a configuration point so that user
> > can configure that path to provide the wsdl of the service instead)
> >
> > What is the behavior of the axis2 in this service path navigation
> > through a browser (or else doing a GET request over the service path)
> > and what do you guys think about this improvement?
> >
> > Thanks,
> > Ruwan
> >
> > On Dec 10, 2007 11:52 PM, Asankha C. Perera <asankha@wso2.com
> > <mailto:asankha@wso2.com>> wrote:
> >
> >     Ruwan
> >
> >     I think what we do right now is the same that a vanilla Axis2 would
> do..
> >     I am not sure if axis2 supports a ?info though, can we check on
> >     axis2-dev/user too?
> >
> >     thanks
> >     asankha
> >
> >     Ruwan Linton wrote:
> >      > Hi all,
> >      >
> >      > For the moment if we browse to the service path (for example if we
> >      > have a proxy service named xxx, then this path is
> >      > http://{host}:{port}/soap/xxx), in other words if we do a GET
> >     request
> >      > on the service path synapse displays the service information as
> pure
> >      > HTML content.
> >      >
> >      > Rather than directly displaying these service information on the
> >      > service path what if we keep that path separate and use ?info
> filter
> >      > to retrieve the service information (i.e.
> >      > http://{host}:{port}/soap/xxx?info will display the service
> >     information)
> >      >
> >      > May be we can define a configuration point on which we can define
> >     what
> >      > will be available under the service path (it can be the service
> WSDL
> >      > or the service info or else any other thing, if you define a
> filter).
> >      > At the same time we can keep the ?wsdl, ?policy and the ?xsd like
> >      > filters also configurable so that one can define what each of these
> >      > would do. I think this adds better flexibility and control over the
> >      > GET request processing.
> >      >
> >      > WDYT?
> >      >
> >      > Thanks,
> >      > Ruwan
> >      >
> >      > --
> >      > Ruwan Linton
> >      > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
> >     ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> >     <mailto:synapse-dev-unsubscribe@ws.apache.org>
> >     For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >     <mailto:synapse-dev-help@ws.apache.org>
> >
> >
> >
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>


-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message