You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2007/12/14 18:58:15 UTC
Re: [Axis2] Displaying the Service Information on the GET request
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
> <ma...@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
> <ma...@ws.apache.org>
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
> <ma...@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
Re: [Axis2] Displaying the Service Information on the GET request
Posted by Eran Chinthaka <ch...@opensource.lk>.
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 <ch...@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
>>> <ma...@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
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>>> <ma...@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
Re: [Axis2] Displaying the Service Information on the GET request
Posted by Ruwan Linton <ru...@gmail.com>.
Asankha,
See my comments in-line,
On Dec 18, 2007 4:34 PM, Asankha C. Perera <as...@wso2.com> wrote:
> Ruwan
> > 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.
> I prefer to keep axis2 configuration of transports in the axis2.xml's
> transport listener/sender configs.. and nhttp.properties to only
> configure advanced options only specific to NIO
So will add this as a parameter to the axis2.xml
>
> > (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)
> Lets keep this for later.. I don't think these would be useful anyway
> for this..
yeah, agreed.
Thanks,
Ruwan
>
>
> asankha
>
> ---------------------------------------------------------------------
> 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"
Re: [Axis2] Displaying the Service Information on the GET request
Posted by "Asankha C. Perera" <as...@wso2.com>.
Ruwan
> 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.
I prefer to keep axis2 configuration of transports in the axis2.xml's
transport listener/sender configs.. and nhttp.properties to only
configure advanced options only specific to NIO
> (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)
Lets keep this for later.. I don't think these would be useful anyway
for this..
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: [Axis2] Displaying the Service Information on the GET request
Posted by Ruwan Linton <ru...@gmail.com>.
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, <ru...@gmail.com> wrote:
> Sorry a minor correction to the earlier mail
>
> On 12/15/07, ruwan.linton@gmail.com <ru...@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 <ch...@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
> > > > <ma...@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
> > > > <ma...@ws.apache.org>
> > > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > > > <ma...@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"
Re: [Axis2] Displaying the Service Information on the GET request
Posted by ru...@gmail.com.
Sorry a minor correction to the earlier mail
On 12/15/07, ruwan.linton@gmail.com <ru...@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 <ch...@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
> > > <ma...@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
> > > <ma...@ws.apache.org>
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > > <ma...@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
Re: [Axis2] Displaying the Service Information on the GET request
Posted by Eran Chinthaka <ch...@opensource.lk>.
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 <ch...@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
>>> <ma...@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
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>>> <ma...@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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Displaying the Service Information on the GET request
Posted by ru...@gmail.com.
Sorry a minor correction to the earlier mail
On 12/15/07, ruwan.linton@gmail.com <ru...@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 <ch...@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
> > > <ma...@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
> > > <ma...@ws.apache.org>
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > > <ma...@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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: [Axis2] Displaying the Service Information on the GET request
Posted by ru...@gmail.com.
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 <ch...@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
> > <ma...@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
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > <ma...@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
Re: [Axis2] Displaying the Service Information on the GET request
Posted by ru...@gmail.com.
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 <ch...@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
> > <ma...@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
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > <ma...@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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org