Great, +1 from me.

[EMAIL PROTECTED] 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.
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    For additional commands, e-mail: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>




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


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to