synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <ruwan.lin...@gmail.com>
Subject Re: [Axis2] Displaying the Service Information on the GET request
Date Tue, 18 Dec 2007 03:56:32 GMT
synapse-devs,

Extending this discussion, we need to figure out the position to place the
configuration point in order to configure the behavior of the GET request
over the service path.

I prefer the nhttp.properties file since this is completely on the (http)
transport level and an entry named "get_on_service" having values "wsdl",
"info" ... etc. (we can add more to this once there are more filters like
what Chinthaka suggested, but I don't think displaying policy and schema is
useful even though we can have them too)

Thoughts?

Thanks,
Ruwan

On Dec 15, 2007 8:51 PM, <ruwan.linton@gmail.com> wrote:

> Sorry a minor correction to the earlier mail
>
> On 12/15/07, ruwan.linton@gmail.com <ruwan.linton@gmail.com> wrote:
> > 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.
>
>           ^^^^^^^^ ^^^^^
> (here the service path should be changed to service information :()
> > 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"
> >
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>



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

Mime
View raw message