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:21:32 GMT
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"

---------------------------------------------------------------------
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