synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <chinth...@opensource.lk>
Subject Re: [Axis2] Displaying the Service Information on the GET request
Date Sun, 23 Dec 2007 04:49:38 GMT
Great, +1 from me.

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



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


Mime
View raw message