Re: REST bindings for Tuscany SCA runtime
IOU all a summary on the wiki - I think now at 50-odd messages that this thread is ready :) We're having a similar conversation on cxf-dev, so I will synthesise the two threads and hopefully have one wiki entry to work off. --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Sure that would be appreciated. Jim On Aug 15, 2006, at 8:56 PM, Sreelatha S wrote: Hi, I am interested in contributing REST bindings to Tuscany. Can I go ahead with this? I have started some ground work in this regard. Please do let me know your thoughts on this. regards Sreelatha - Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
I have also been investigating how to implement a REST binding for Tuscany, perhaps there is a way we could work together on this. -Bert On 8/15/06, Sreelatha S <[EMAIL PROTECTED]> wrote: Hi, I am interested in contributing REST bindings to Tuscany. Can I go ahead with this? I have started some ground work in this regard. Please do let me know your thoughts on this. regards Sreelatha - Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
Re: REST bindings for Tuscany SCA runtime
Hi Bert, Sreelatha, Have you any thoughts on how a REST binding will need to influence the SCA programming model? rgds --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Hi Oisin, I am still at the point where I am trying to get my head really wrapped around how Tuscany works and how one would go about creating a REST binding, so I'm afraid I'm not quite at the point where I am capable of speaking very intelligently on the subject. Have you put much thought towards the subject of a REST binding? Are there things about which you believe we should be aware? -Bert On 8/16/06, Oisin Hurley <[EMAIL PROTECTED]> wrote: Hi Bert, Sreelatha, Have you any thoughts on how a REST binding will need to influence the SCA programming model? rgds --oh - 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]
Re: REST bindings for Tuscany SCA runtime
On Aug 16, 2006, at 11:51 AM, Bert Lamb wrote: Hi Oisin, I am still at the point where I am trying to get my head really wrapped around how Tuscany works and how one would go about creating a REST binding, so I'm afraid I'm not quite at the point where I am capable of speaking very intelligently on the subject. Have you put much thought towards the subject of a REST binding? Are there things about which you believe we should be aware? In terms of the basic transport, in M1 we had a JSON-RPC binding that supported JSON encoded data over HTTP. We have not got around yet to porting that to the new structure in the trunk. Looking at that would be a good way to dig into how Tuscany works. Oisin may have been referring to how REST would impact the programming model rather than the implementation of bindings. For example, how would cache information in the request be handled by the binding and/or exposed to the application code? What is the mapping between REST resources and SCA services? IMO we can tackle this in to stages. First one is to get the basic transports working (like JSON-RPC, XML over messaging, HTML over HTTP etc.); that would at least allow SCA applications to provide/access REST resources. The second stage would be to support more of the semantics of RESTful interactions. Or, I may be talking garbage and would be happy to learn more :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Hi Bert, I was planning to pick up any existing binding in Tuscany to understand its programming model. As Jeremy has suggested we could look at the JSON-RPC binding in M1. Please do let me know if you have any other thoughts on how we should move forward. Thanks. Sreelatha Bert Lamb <[EMAIL PROTECTED]> wrote: I have also been investigating how to implement a REST binding for Tuscany, perhaps there is a way we could work together on this. -Bert On 8/15/06, Sreelatha S wrote: > > Hi, > I am interested in contributing REST bindings to Tuscany. > Can I go ahead with this? I have started some ground work in this > regard. > Please do let me know your thoughts on this. > > regards > Sreelatha > > > - > Do you Yahoo!? > Next-gen email? Have it all with the all-new Yahoo! Mail Beta. > - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: REST bindings for Tuscany SCA runtime
Hi Bert,
I am still at the point where I am trying to get my head really
wrapped around how Tuscany works
I will be travelling the same road soon ;)
Have you put much thought towards the subject of a REST binding? Are
there things about which you believe we should be aware?
Well, the thing that comes to mind first is the mismatch between
the basic REST approach of using a fixed set of 'verbs' richly flexible
data and the Interfaces approach, which uses an open-ended set of
'verbs' (read: operations) and constrained strongly-typed data.
[small REST primer - skip if you know all this stuff]
The short document at [0] below characterises some of the issues of
developing a (Web) service using REST principles and is useful and
the wikipedia link at [1] has a good example (generic, not Tuscany
specific) :
Say you have a service that has methods
getUser()
addUser()
removeUser()
updateUser()
then you might use code like:
exampleAppObject = new ExampleApp("example.com:1234")
exampleAppObject.getUser()
to get details of a user. This is the interface or unconstrained
verbs approach.
Now, let's flip over to a REST means of getting the same
information. In this case, you are limited to small set of
well-defined operations, which map very well to the CRUD [3]
operators that a persistence system must provide. Because
of this stricture, you need to ramp up the diversity of
nouns (or resources, or maybe objects, but really the concept
of a resource may not equal an object in programming terms,
many resources could be 'supported' by a single object).
These resources (which is the accepted term) are represented,
uniquely, and immutably, by URIs. So taking the example
above and REST-ing it you get resources:
http://example.com/users/
http://example.com/users/{user} (one for each user)
and then you might use code like:
userResource = new Resource("http://example.com/users/001";)
userResource.get()
and you get the same information as the Interface-y example
previously.
REST is liked by many, for many reasons, but one good on is
that it's scalable (the web is an
example, although there is an extra factor that makes the
web scalable and that is the 404) in the sense that everyone
supports the same 'interface' and the semantics of the interface
are simple and clear.
In practical terms, this means that you can just join the
web, as a resource, and you will immediately fit in. No adapters
required :)
[end of small REST primer]
My interest in responding to your initial mail was that I am
currently attempting to use RESTian principles in another
project and I am finding myself making lots of interesting
decisions that I would not have made using the Interface
approach that I have used for more years than I care to
remember. Using the REST principles has deeply impacted they
way I've approached the development of the development of
the project -- in a good way :)
I'm sure you've noticed the example I gave earlier on the
programming model is client-specific and so impacts on only
part of a prospective RESTian addition to Tuscany. There is an
impact on the server too, and that's a direct consequence of
the 'few verbs' approach - talking from a programming language
perspective, every 'servant' (or resource implementation may
be a better way to put it) will have a tiny interface.
My point is that if Tuscany wants to support REST style -
a goal which I think is good, right and true - it's a job
that will involve constructing a binding extension,
re-working the Basic Client Model (see 1.3 in Java C&I spec)
and adding some new annotations to the Java interface (or
maybe adding a new interface type). Note that the same will
apply to other language mappings too since REST is language
neutral (it's also protocol neutral too as an architectural
style, but assuming HTTP as the #1 priority would be safe
enough :)
On the annotations I mentioned, consider something like:
package services.hello;
import org.osoa.sca.annotations.*;
@Remotable
public interface HelloService {
@RESTMethod(RestMethods.RETRIEVE)
@RESTBaseURIContext("/foo/bar/sossages")
String hello();
}
Here I've decorated the ubiquitous HW example from JC&I 1.2.1.1
with some spanky new annotations. This example indicates to the
runtime that the hello() method should be called on this interface
should the 'RETRIEVE' REST method (for HTTP this is 'GET') appear
on the dispatch, directed to a URI that starts with the string
specified in with the RESTBaseURIContext (now - this is probably
the wrong way to do it, but I just trying to illustrate the
broad outlines of an approach, i.e. I am making it up).
Note that the concept of XML/HTTP interchange may be RESTful,
but indeed may not. However, it is the basis for an implementation
of a RESTful approach (given HTTP as the transport) and is
useful in an of itself (especially for so-called Web 2.0 apps).
Methinks I've said enough for now, thank you for reading this
far if indeed you have
Re: REST bindings for Tuscany SCA runtime
Oisin may have been referring to how REST would impact the programming model rather than the implementation of bindings. For example, how would cache information in the request be handled by the binding and/or exposed to the application code? What is the mapping between REST resources and SCA services? Caching, which is only made possible by the fact the RESTful retrieves are idempotent, might be difficult to do effectively since it's not really possible to control what the programmer does from within a mapped retrieve method in the implementation short of giving them a new execution environment to be bad in :) IMO we can tackle this in to stages. First one is to get the basic transports working (like JSON-RPC, XML over messaging, HTML over HTTP etc.); that would at least allow SCA applications to provide/ access REST resources. The second stage would be to support more of the semantics of RESTful interactions. +1 --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
On 8/16/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: In terms of the basic transport, in M1 we had a JSON-RPC binding that supported JSON encoded data over HTTP. We have not got around yet to porting that to the new structure in the trunk. Looking at that would be a good way to dig into how Tuscany works. I can make an attempt to try and port the jsonrpc binding from M1 over to trunk style extensions if this would be appreciated. I agree that should help me get an understanding of how some of Tuscany works. Oisin may have been referring to how REST would impact the programming model rather than the implementation of bindings. For example, how would cache information in the request be handled by the binding and/or exposed to the application code? What is the mapping between REST resources and SCA services? Yes, the more I read, the more I wonder if trying to support REST style web applications in SCA is going to become a square peg in a round hole problem. I've only begun really looking at this though, and welcome any thoughts on the subject of how one might attempt to interface REST resources in SCA. -Bert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Hi Bert, I agree there's going to be some challenges to solve to integrate REST well with Tuscany, I'll stay out of that for now and focus on how to get you started with bindings. Implementing a simple binding would be a good place to start so if you want to port over the old jsonrpc binding that would be great. The code for that is at, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/sca/bindings/binding.jsonrpc/, and there's a sample, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/samples/sca/helloworldjsonrpc/. You could download the Tuscany M1 distribution if you want to see the sample running. I'd start by taking the sample and getting it to fit in with the new code base - convert the SCDL to the new format, and get the war packaging correct. You could use the Axis2 WS sample as a model for that which is at, http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/helloworldws/. (The WAR packaging is going to change once I finish the TuscanyServletListener and ServletHost work, I'll let you know when that goes in) Once you get the WAR right when you deploy it to tomcat you should see an exception about an unrecognized element: binding.jsonrpc, thats because Tuscany doesn't have a binding for it so now you need to convert the binding over to the new Tuscany runtime. There's several bindings to use as models, the RMI or echo ones are simple, the Axis2 uses the ServletHost which you'll also need to do: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.rmi/ http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/echo.binding/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/ Copy the existing echo or RMI binding, rename all 'rmi' to jsonrpc', then try to hook up the JSONRPCEntryPointServlet based on what the Axis2 binding is doing. You wont need the RMIReference or RMIInvoker classes as jsonrpc only supports services. There's also a binding using DWR instead of json-rpc-java which you port to the new runtime and its a bit more interesting as it also supports references (well, externalServices) so you could look at that as well if you're interested: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/. If you search back in the dev list archives there's a few mails where we talk about what these two binding do. Hope this helps, ...ant On 8/17/06, Bert Lamb <[EMAIL PROTECTED]> wrote: On 8/16/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > In terms of the basic transport, in M1 we had a JSON-RPC binding that > supported JSON encoded data over HTTP. We have not got around yet to > porting that to the new structure in the trunk. Looking at that would > be a good way to dig into how Tuscany works. > I can make an attempt to try and port the jsonrpc binding from M1 over to trunk style extensions if this would be appreciated. I agree that should help me get an understanding of how some of Tuscany works. > Oisin may have been referring to how REST would impact the > programming model rather than the implementation of bindings. For > example, how would cache information in the request be handled by the > binding and/or exposed to the application code? What is the mapping > between REST resources and SCA services? > Yes, the more I read, the more I wonder if trying to support REST style web applications in SCA is going to become a square peg in a round hole problem. I've only begun really looking at this though, and welcome any thoughts on the subject of how one might attempt to interface REST resources in SCA. -Bert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Thanks Ant, that helps a lot! I'll have a look and see what I can get working. -Bert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
REST is a very generic term, and I think it's more like a resource/service naming pattern (URL/URI). When we say REST bindings, what are we expecting as the REST Service ? Also, SOAP 1.2 now supports GET as a message response exchange pattern and I think that a intimate combination of REST style GETs with a Webservices style SOAP response would be also a good scenario to support, not sure if as a REST binding, or as part of the Webservices binding. - Luciano On 8/18/06, Bert Lamb <[EMAIL PROTECTED]> wrote: Thanks Ant, that helps a lot! I'll have a look and see what I can get working. -Bert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: REST bindings for Tuscany SCA runtime
Oisin Hurley wrote:
Hi Bert,
I am still at the point where I am trying to get my head really
wrapped around how Tuscany works
I will be travelling the same road soon ;)
Have you put much thought towards the subject of a REST binding? Are
there things about which you believe we should be aware?
Well, the thing that comes to mind first is the mismatch between
the basic REST approach of using a fixed set of 'verbs' richly flexible
data and the Interfaces approach, which uses an open-ended set of
'verbs' (read: operations) and constrained strongly-typed data.
[small REST primer - skip if you know all this stuff]
The short document at [0] below characterises some of the issues of
developing a (Web) service using REST principles and is useful and
the wikipedia link at [1] has a good example (generic, not Tuscany
specific) :
Say you have a service that has methods
getUser()
addUser()
removeUser()
updateUser()
then you might use code like:
exampleAppObject = new ExampleApp("example.com:1234")
exampleAppObject.getUser()
to get details of a user. This is the interface or unconstrained
verbs approach.
Now, let's flip over to a REST means of getting the same
information. In this case, you are limited to small set of
well-defined operations, which map very well to the CRUD [3]
operators that a persistence system must provide. Because
of this stricture, you need to ramp up the diversity of
nouns (or resources, or maybe objects, but really the concept
of a resource may not equal an object in programming terms,
many resources could be 'supported' by a single object).
These resources (which is the accepted term) are represented,
uniquely, and immutably, by URIs. So taking the example
above and REST-ing it you get resources:
http://example.com/users/
http://example.com/users/{user} (one for each user)
and then you might use code like:
userResource = new Resource("http://example.com/users/001";)
userResource.get()
and you get the same information as the Interface-y example
previously.
REST is liked by many, for many reasons, but one good on is
that it's scalable (the web is an
example, although there is an extra factor that makes the
web scalable and that is the 404) in the sense that everyone
supports the same 'interface' and the semantics of the interface
are simple and clear.
In practical terms, this means that you can just join the
web, as a resource, and you will immediately fit in. No adapters
required :)
[end of small REST primer]
My interest in responding to your initial mail was that I am
currently attempting to use RESTian principles in another
project and I am finding myself making lots of interesting
decisions that I would not have made using the Interface
approach that I have used for more years than I care to
remember. Using the REST principles has deeply impacted they
way I've approached the development of the development of
the project -- in a good way :)
I'm sure you've noticed the example I gave earlier on the
programming model is client-specific and so impacts on only
part of a prospective RESTian addition to Tuscany. There is an
impact on the server too, and that's a direct consequence of
the 'few verbs' approach - talking from a programming language
perspective, every 'servant' (or resource implementation may
be a better way to put it) will have a tiny interface.
My point is that if Tuscany wants to support REST style -
a goal which I think is good, right and true - it's a job
that will involve constructing a binding extension,
re-working the Basic Client Model (see 1.3 in Java C&I spec)
and adding some new annotations to the Java interface (or
maybe adding a new interface type). Note that the same will
apply to other language mappings too since REST is language
neutral (it's also protocol neutral too as an architectural
style, but assuming HTTP as the #1 priority would be safe
enough :)
On the annotations I mentioned, consider something like:
package services.hello;
import org.osoa.sca.annotations.*;
@Remotable
public interface HelloService {
@RESTMethod(RestMethods.RETRIEVE)
@RESTBaseURIContext("/foo/bar/sossages")
String hello();
}
Here I've decorated the ubiquitous HW example from JC&I 1.2.1.1
with some spanky new annotations. This example indicates to the
runtime that the hello() method should be called on this interface
should the 'RETRIEVE' REST method (for HTTP this is 'GET') appear
on the dispatch, directed to a URI that starts with the string
specified in with the RESTBaseURIContext (now - this is probably
the wrong way to do it, but I just trying to illustrate the
broad outlines of an approach, i.e. I am making it up).
Note that the concept of XML/HTTP interchange may be RESTful,
but indeed may not. However, it is the basis for an implementation
of a RESTful approach (given HTTP as the transport) and is
useful in an of itself (especially for so-called Web 2.0 apps).
Methinks I've said enough for now, thank you for reading this
fa
Re: REST bindings for Tuscany SCA runtime
Sebastien
When you say this should tie with DAS, are you assuming that the REST
services would emit XML (and not JSON or any other format) and then DAS
would be able to consume the xml and bind to a data object ?
- Luciano
On 8/21/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Oisin Hurley wrote:
> Hi Bert,
>
>> I am still at the point where I am trying to get my head really
>> wrapped around how Tuscany works
>
> I will be travelling the same road soon ;)
>
>> Have you put much thought towards the subject of a REST binding? Are
>> there things about which you believe we should be aware?
>
> Well, the thing that comes to mind first is the mismatch between
> the basic REST approach of using a fixed set of 'verbs' richly flexible
> data and the Interfaces approach, which uses an open-ended set of
> 'verbs' (read: operations) and constrained strongly-typed data.
>
> [small REST primer - skip if you know all this stuff]
>
> The short document at [0] below characterises some of the issues of
> developing a (Web) service using REST principles and is useful and
> the wikipedia link at [1] has a good example (generic, not Tuscany
> specific) :
>
> Say you have a service that has methods
>
> getUser()
> addUser()
> removeUser()
> updateUser()
>
> then you might use code like:
>
> exampleAppObject = new ExampleApp("example.com:1234")
> exampleAppObject.getUser()
>
> to get details of a user. This is the interface or unconstrained
> verbs approach.
>
> Now, let's flip over to a REST means of getting the same
> information. In this case, you are limited to small set of
> well-defined operations, which map very well to the CRUD [3]
> operators that a persistence system must provide. Because
> of this stricture, you need to ramp up the diversity of
> nouns (or resources, or maybe objects, but really the concept
> of a resource may not equal an object in programming terms,
> many resources could be 'supported' by a single object).
>
> These resources (which is the accepted term) are represented,
> uniquely, and immutably, by URIs. So taking the example
> above and REST-ing it you get resources:
>
> http://example.com/users/
> http://example.com/users/{user} (one for each user)
>
> and then you might use code like:
>
> userResource = new Resource("http://example.com/users/001";)
> userResource.get()
>
> and you get the same information as the Interface-y example
> previously.
>
> REST is liked by many, for many reasons, but one good on is
> that it's scalable (the web is an
> example, although there is an extra factor that makes the
> web scalable and that is the 404) in the sense that everyone
> supports the same 'interface' and the semantics of the interface
> are simple and clear.
>
> In practical terms, this means that you can just join the
> web, as a resource, and you will immediately fit in. No adapters
> required :)
>
> [end of small REST primer]
>
> My interest in responding to your initial mail was that I am
> currently attempting to use RESTian principles in another
> project and I am finding myself making lots of interesting
> decisions that I would not have made using the Interface
> approach that I have used for more years than I care to
> remember. Using the REST principles has deeply impacted they
> way I've approached the development of the development of
> the project -- in a good way :)
>
> I'm sure you've noticed the example I gave earlier on the
> programming model is client-specific and so impacts on only
> part of a prospective RESTian addition to Tuscany. There is an
> impact on the server too, and that's a direct consequence of
> the 'few verbs' approach - talking from a programming language
> perspective, every 'servant' (or resource implementation may
> be a better way to put it) will have a tiny interface.
>
> My point is that if Tuscany wants to support REST style -
> a goal which I think is good, right and true - it's a job
> that will involve constructing a binding extension,
> re-working the Basic Client Model (see 1.3 in Java C&I spec)
> and adding some new annotations to the Java interface (or
> maybe adding a new interface type). Note that the same will
> apply to other language mappings too since REST is language
> neutral (it's also protocol neutral too as an architectural
> style, but assuming HTTP as the #1 priority would be safe
> enough :)
>
> On the annotations I mentioned, consider something like:
>
> package services.hello;
>
> import org.osoa.sca.annotations.*;
>
> @Remotable
> public interface HelloService {
>
> @RESTMethod(RestMethods.RETRIEVE)
> @RESTBaseURIContext("/foo/bar/sossages")
> String hello();
> }
>
> Here I've decorated the ubiquitous HW example from JC&I 1.2.1.1
> with some spanky new annotations. This example indicates to the
> runtime that the hello() method should be called on this interface
> should the 'RETRIEVE' REST method (for HTTP this is 'GET') appear
> on the dispatch, directed to a URI that starts with the s
Re: REST bindings for Tuscany SCA runtime
REST is a very generic term, and I think it's more like a resource/ service naming pattern (URL/URI). When we say REST bindings, what are we expecting as the REST Service ? The resource part is really important, but the small interface part is important too, as are the expected behaviours of the interface: i.e., GET is idempotent, PUT will replace a resource, POST will perform a partial update of the state of a resource. IMHO the first place we could go is an XML over HTTP binding and some kind of 'generic' processing method in the service (see [0] for an example of what's RESTful with JAX-WS, which might prompt some ideas). cheers --oh [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Just as a precaution reminder about PUT and DELETE, although they are probably the right way of doing some kind of actions, in reality, firewalls and deployment environments usually block those kind of operations. - Luciano On 8/22/06, Oisin Hurley <[EMAIL PROTECTED]> wrote: > REST is a very generic term, and I think it's more like a resource/ > service > naming pattern (URL/URI). When we say REST bindings, what are we > expecting > as the REST Service ? The resource part is really important, but the small interface part is important too, as are the expected behaviours of the interface: i.e., GET is idempotent, PUT will replace a resource, POST will perform a partial update of the state of a resource. IMHO the first place we could go is an XML over HTTP binding and some kind of 'generic' processing method in the service (see [0] for an example of what's RESTful with JAX-WS, which might prompt some ideas). cheers --oh [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: REST bindings for Tuscany SCA runtime
Axis2 also has some built in REST support, and as we already have an Axis2 binding it would be relatively easy to get a Tuscany REST binding going using Axis2. All that you need to do is change the Tuscany code to use the Axis2 REST servlet instead of the SOAP one, and change the code where we set up the Axis2 config to set some flags to enable the REST support. With a bit of refactoring of the existing Axis2 binding and changing a few things from private to protected you could probably get something going by subclassing the existing Axis2 binding with minimal new code. I think we should make a better, more 'RESTful' binding than this in the long run, but this approach would be an easy first start. ...ant On 8/22/06, Oisin Hurley <[EMAIL PROTECTED]> wrote: > REST is a very generic term, and I think it's more like a resource/ > service > naming pattern (URL/URI). When we say REST bindings, what are we > expecting > as the REST Service ? The resource part is really important, but the small interface part is important too, as are the expected behaviours of the interface: i.e., GET is idempotent, PUT will replace a resource, POST will perform a partial update of the state of a resource. IMHO the first place we could go is an XML over HTTP binding and some kind of 'generic' processing method in the service (see [0] for an example of what's RESTful with JAX-WS, which might prompt some ideas). cheers --oh [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Luciano Resende wrote: [snip] Sebastien When you say this should tie with DAS, are you assuming that the REST services would emit XML (and not JSON or any other format) and then DAS would be able to consume the xml and bind to a data object ? - Luciano Luciano, I am assuming that REST "services" will flow XML / HTTP. SDO is a one of the possible representations (data bindings) for XML. In the Tuscany C++ runtime this is the only data binding that we support at the moment. My comment about DAS was about something else. I was just expressing my naive view that: - if REST is about creating/retrieving/updating/deleting a Customer resource for example (viewing the web as a giant database) - and DAS is about accessing... creating/retrieving/updating/deleting a Customer in a database. - then these two should nicely fit together... I'm just exploring ideas here, but it may be useful to try to build a realistic scenario exposing a REST interface and using DAS to access the data in a database... or maybe the other way around build a DAS service on top of a REST binding instead of a database API? Scenarios like that would help us understand better how REST and DAS fit together... Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
I think anything that is sent to/from a SCA REST binding needs to either be Plain Old XML or JSON and not SOAP. SOAP is generally what makes most RESTifarians shudder :) -Bert On 8/18/06, Luciano Resende <[EMAIL PROTECTED]> wrote: Also, SOAP 1.2 now supports GET as a message response exchange pattern and I think that a intimate combination of REST style GETs with a Webservices style SOAP response would be also a good scenario to support, not sure if as a REST binding, or as part of the Webservices binding. - Luciano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
This sounds like a very good place to start to be able to expose SCA resources in a REST way, but I think the more interesting and more difficult challenge will be to figure out how to get SCA to consume some of the growing number of REST resources that are being exposed on the net now. Jean-Sebastien's approach seems to be a step in this direction. -Bert PS: I'm still trudging through the json-rpc port from M1and slowly but surely understanding more bits an pieces of the emails on this list :) On 8/22/06, ant elder <[EMAIL PROTECTED]> wrote: Axis2 also has some built in REST support, and as we already have an Axis2 binding it would be relatively easy to get a Tuscany REST binding going using Axis2. All that you need to do is change the Tuscany code to use the Axis2 REST servlet instead of the SOAP one, and change the code where we set up the Axis2 config to set some flags to enable the REST support. With a bit of refactoring of the existing Axis2 binding and changing a few things from private to protected you could probably get something going by subclassing the existing Axis2 binding with minimal new code. I think we should make a better, more 'RESTful' binding than this in the long run, but this approach would be an easy first start. ...ant On 8/22/06, Oisin Hurley <[EMAIL PROTECTED]> wrote: > > > REST is a very generic term, and I think it's more like a resource/ > > service > > naming pattern (URL/URI). When we say REST bindings, what are we > > expecting > > as the REST Service ? > > The resource part is really important, but the small interface part is > important too, as are the expected behaviours of the interface: i.e., > GET is idempotent, PUT will replace a resource, POST will perform a > partial update of the state of a resource. > > IMHO the first place we could go is an XML over HTTP binding and some > kind > of 'generic' processing method in the service (see [0] for an example > of what's RESTful with JAX-WS, which might prompt some ideas). > > cheers > --oh > > [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ > > > - > 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]
Re: REST bindings for Tuscany SCA runtime
I think anything that is sent to/from a SCA REST binding needs to either be Plain Old XML or JSON and not SOAP. SOAP is generally what makes most RESTifarians shudder :) It's the encoding of the method in the XML body that is the anathema :) --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
bl says: Jean-Sebastien's approach seems to be a step in this direction. +1 --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Apologies for addressing the emails in this thread out of order :)
I was on a similar track, thinking about implementing a REST
binding for Tuscany C++. I agree with you that the REST pattern is
about resources, so we need to go further than just sending XML
service requests over HTTP, and understand what it means to work
with resources in an SCA application.
I was thinking about starting with something very simple like this:
In an SCDL component reference:
http://my.business.objects/#Customer"/>
and later in a composite reference:
QName "http://my.business.objects/#Customer"; specifies an XSD
complex type describing my Customer business object.
loads my new REST binding extension that knows how
to send Customer resource requests over HTTP.
indicates a fixed interface pattern with the
resource management / HTTP verbs.
In the client:
customers.get("http://my.customer.database.com/customers/1234";);
returns an instance of the Customer XSD complex type
customers.put("http://my.customer.database.com/customers/1234";,
customerDataObject) updates customer 1234 with a Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns
a list of URIs to the customers.
On the server, the CustomerResource component implements the
Customer resource management verbs:
class CustomerResource {
DataObject get(string uri);
void post(string uri, DataObject customer);
void put(string uri, DataObject customer);
void delete(string uri);
list list(string uris);
}
Yes I do like it, but I still have a fond attachment to the annotation
driven state-change -> method mapping :)
You have .put and .get in the client example, maybe the .post should be
something like
customers.post(uri, state-diff)
where state-diff is a state format dependent serialization.
Also, I was thinking that somehow our REST work should tie in with
the DAS work that we're doing in Tuscany.
+1 - I know little about the DAS stuff as yet, but the REST/CRUD/BREAD
approach has a strong affinity for data sources. IMHO this would be
a great first step!
--oh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
In the client:
customers.get("http://my.customer.database.com/customers/1234";);
returns an instance of the Customer XSD complex type
customers.put("http://my.customer.database.com/customers/1234";,
customerDataObject) updates customer 1234 with a Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
On the server, the CustomerResource component implements the Customer
resource management verbs:
class CustomerResource {
DataObject get(string uri);
void post(string uri, DataObject customer);
void put(string uri, DataObject customer);
void delete(string uri);
list list(string uris);
}
Also, I was thinking that somehow our REST work should tie in with the
DAS work that we're doing in Tuscany.
Thoughts?
I have spent a little time thinking about DAS and REST ... no epiphany
so far. Some RDB vendors offer URL access to relational data with an
option to return results as xml with something like this:
http://localhost/myDatabase?sql=SELECT+firstname,lastname+FROM+employees+FOR+XML+AUTO
So, this seems quasi-restful although what is returned is really the
results of a query rather than a resource. I suppose this would be more
restful and similar to Sebastien's example if the get returned a list of
urls of Employees that satisfied the query.
I am not sure we would want to embed SQL in the URL but it also does not
seem to make much sense to invent a new query language. Without a
fairly sophisticated query language, how could a client retrieve a graph
of results like: Customers-Orders-LineItems? I am starting to ramble.
I need to think about this a bit more.
--Kevin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
So, trying to catchup with many replies to the REST thread...
+1 on DAS supporting all data access on the REST service side...
Also, trying to get a summary of points here, we are saying
1.We need to provide a REST binding for SCA
2.We would provide a REST service using DAS/SDO and the SCA REST binding
would consume this REST service
3.We would probably create a sample app that would show the usage and
binding of all these (and we need a scenario here)
I could definitely help with 2 and 3... also, I'm finishing up a DAS sample
that, with little change could be transformed as the REST service similar to
what was mentioned by Kevin... (should be in the trunk in the next day or
so)
- Luciano
On 8/23/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
>
> In the client:
> customers.get("http://my.customer.database.com/customers/1234";);
> returns an instance of the Customer XSD complex type
> customers.put("http://my.customer.database.com/customers/1234";,
> customerDataObject) updates customer 1234 with a Customer instance.
> customers.get("http://my.customer.database.com/customers/";) returns a
> list of URIs to the customers.
>
> On the server, the CustomerResource component implements the Customer
> resource management verbs:
> class CustomerResource {
> DataObject get(string uri);
> void post(string uri, DataObject customer);
> void put(string uri, DataObject customer);
> void delete(string uri);
> list list(string uris);
> }
>
> Also, I was thinking that somehow our REST work should tie in with the
> DAS work that we're doing in Tuscany.
>
> Thoughts?
I have spent a little time thinking about DAS and REST ... no epiphany
so far. Some RDB vendors offer URL access to relational data with an
option to return results as xml with something like this:
http://localhost/myDatabase?sql=SELECT+firstname,lastname+FROM+employees+FOR+XML+AUTO
So, this seems quasi-restful although what is returned is really the
results of a query rather than a resource. I suppose this would be more
restful and similar to Sebastien's example if the get returned a list of
urls of Employees that satisfied the query.
I am not sure we would want to embed SQL in the URL but it also does not
seem to make much sense to invent a new query language. Without a
fairly sophisticated query language, how could a client retrieve a graph
of results like: Customers-Orders-LineItems? I am starting to ramble.
I need to think about this a bit more.
--Kevin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-
Luciano Resende
SOA Opensource - Apache Tuscany
-
Re: REST bindings for Tuscany SCA runtime
More ideas and questions below.
Oisin Hurley wrote:
Apologies for addressing the emails in this thread out of order :)
I was on a similar track, thinking about implementing a REST binding
for Tuscany C++. I agree with you that the REST pattern is about
resources, so we need to go further than just sending XML service
requests over HTTP, and understand what it means to work with
resources in an SCA application.
I was thinking about starting with something very simple like this:
In an SCDL component reference:
http://my.business.objects/#Customer"/>
and later in a composite reference:
QName "http://my.business.objects/#Customer"; specifies an XSD complex
type describing my Customer business object.
loads my new REST binding extension that knows how to
send Customer resource requests over HTTP.
indicates a fixed interface pattern with the
resource management / HTTP verbs.
In the client:
customers.get("http://my.customer.database.com/customers/1234";);
returns an instance of the Customer XSD complex type
customers.put("http://my.customer.database.com/customers/1234";,
customerDataObject) updates customer 1234 with a Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
On the server, the CustomerResource component implements the Customer
resource management verbs:
class CustomerResource {
DataObject get(string uri);
void post(string uri, DataObject customer);
void put(string uri, DataObject customer);
void delete(string uri);
list list(string uris);
}
Yes I do like it, but I still have a fond attachment to the annotation
driven state-change -> method mapping :)
What do you think about the following approach:
a) If you put no annotations in your code then you have to stick to the
fixed pattern with fixed method names, and you write the side SCDL file
that turns your code into a component and publishes the REST endpoint.
b) If you want more flexibility to map state changes to nicer method
names then you use annotations as your were proposing earlier in this
thread. The annotations also allow you to completely avoid writing SCDL
and specify the details of the binding like the base URI for the
resources...
Thoughts?
You have .put and .get in the client example, maybe the .post should be
something like
customers.post(uri, state-diff)
Ah! interesting, I never thought about that before, looks like there
could be a pretty good fit with SDO with the following:
customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ...
This would be an interesting usage of SDO change summaries IMO,
obviously just as an option as you should be able to format your state
diff in any format you want as long as it's understood by your application.
What do you think?
where state-diff is a state format dependent serialization.
Also, I was thinking that somehow our REST work should tie in with
the DAS work that we're doing in Tuscany.
+1 - I know little about the DAS stuff as yet, but the REST/CRUD/BREAD
approach has a strong affinity for data sources. IMHO this would be
a great first step!
--oh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Ok, my I tried to send this email earlier, but it bounced as spam, so I'm going to try again with a link to my attachment and see if that helps So I'm sure it is something stupid, but I'm missing something. I've got the sample webapp packaged correctly (I think) and it was giving the error about the unrecognized element binding.jasonrpc. I then added my jsonrpc-1.0-SNAPSHOT.jar that I thought was at least mocked up correctly to get me onto the next error, but it doesn't seem to be getting picked up, and I still have the unrecognized element binding.jsonrpc error. Here is a link to a zip of my binding.jsonrpc source tree. Any ideas? http://bertlamb.com/binding.jsonrpc.zip Thanks! -Bert On 8/18/06, ant elder <[EMAIL PROTECTED]> wrote: Hi Bert, I agree there's going to be some challenges to solve to integrate REST well with Tuscany, I'll stay out of that for now and focus on how to get you started with bindings. Implementing a simple binding would be a good place to start so if you want to port over the old jsonrpc binding that would be great. The code for that is at, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/sca/bindings/binding.jsonrpc/, and there's a sample, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/samples/sca/helloworldjsonrpc/. You could download the Tuscany M1 distribution if you want to see the sample running. I'd start by taking the sample and getting it to fit in with the new code base - convert the SCDL to the new format, and get the war packaging correct. You could use the Axis2 WS sample as a model for that which is at, http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/helloworldws/. (The WAR packaging is going to change once I finish the TuscanyServletListener and ServletHost work, I'll let you know when that goes in) Once you get the WAR right when you deploy it to tomcat you should see an exception about an unrecognized element: binding.jsonrpc, thats because Tuscany doesn't have a binding for it so now you need to convert the binding over to the new Tuscany runtime. There's several bindings to use as models, the RMI or echo ones are simple, the Axis2 uses the ServletHost which you'll also need to do: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.rmi/ http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/echo.binding/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/ Copy the existing echo or RMI binding, rename all 'rmi' to jsonrpc', then try to hook up the JSONRPCEntryPointServlet based on what the Axis2 binding is doing. You wont need the RMIReference or RMIInvoker classes as jsonrpc only supports services. There's also a binding using DWR instead of json-rpc-java which you port to the new runtime and its a bit more interesting as it also supports references (well, externalServices) so you could look at that as well if you're interested: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/. If you search back in the dev list archives there's a few mails where we talk about what these two binding do. Hope this helps, ...ant On 8/17/06, Bert Lamb <[EMAIL PROTECTED]> wrote: > > On 8/16/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > > > In terms of the basic transport, in M1 we had a JSON-RPC binding that > > supported JSON encoded data over HTTP. We have not got around yet to > > porting that to the new structure in the trunk. Looking at that would > > be a good way to dig into how Tuscany works. > > > > I can make an attempt to try and port the jsonrpc binding from M1 over > to trunk style extensions if this would be appreciated. I agree that > should help me get an understanding of how some of Tuscany works. > > > Oisin may have been referring to how REST would impact the > > programming model rather than the implementation of bindings. For > > example, how would cache information in the request be handled by the > > binding and/or exposed to the application code? What is the mapping > > between REST resources and SCA services? > > > > Yes, the more I read, the more I wonder if trying to support REST > style web applications in SCA is going to become a square peg in a > round hole problem. I've only begun really looking at this though, > and welcome any thoughts on the subject of how one might attempt to > interface REST resources in SCA. > > -Bert > > - > 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]
Re: REST bindings for Tuscany SCA runtime
It looks pretty good. I'm guessing the system scdl being used by the web app doesn't include the scdl for your binding. The way the sample webapps are done right now with all the jars going into the webapp lib you need to add all extensions to the system scdl being used. In you web.xml there's a parameter systemScdlPath which is set to /META-INF/sca/webapp.system.scdl. That will pick up the resource from the webapp-host.jar. Update that file or copy it somewhere else and update the systemScdlPath to point at the new file, and add in your jsonrpc scdl elements. Once we get extension plugabilty going properly in the samples this wont be necessary. ...ant On 8/24/06, Bert Lamb <[EMAIL PROTECTED]> wrote: Ok, my I tried to send this email earlier, but it bounced as spam, so I'm going to try again with a link to my attachment and see if that helps So I'm sure it is something stupid, but I'm missing something. I've got the sample webapp packaged correctly (I think) and it was giving the error about the unrecognized element binding.jasonrpc. I then added my jsonrpc-1.0-SNAPSHOT.jar that I thought was at least mocked up correctly to get me onto the next error, but it doesn't seem to be getting picked up, and I still have the unrecognized element binding.jsonrpc error. Here is a link to a zip of my binding.jsonrpc source tree. Any ideas? http://bertlamb.com/binding.jsonrpc.zip Thanks! -Bert On 8/18/06, ant elder <[EMAIL PROTECTED]> wrote: > Hi Bert, > > I agree there's going to be some challenges to solve to integrate REST well > with Tuscany, I'll stay out of that for now and focus on how to get you > started with bindings. Implementing a simple binding would be a good place > to start so if you want to port over the old jsonrpc binding that would be > great. > > The code for that is at, > http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/sca/bindings/binding.jsonrpc/ , > and there's a sample, > http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/samples/sca/helloworldjsonrpc/ . > You could download the Tuscany M1 distribution if you want to see the sample > running. > > I'd start by taking the sample and getting it to fit in with the new code > base - convert the SCDL to the new format, and get the war packaging > correct. You could use the Axis2 WS sample as a model for that which is at, > http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/helloworldws/ . > (The WAR packaging is going to change once I finish the > TuscanyServletListener and ServletHost work, I'll let you know when that > goes in) > > Once you get the WAR right when you deploy it to tomcat you should see an > exception about an unrecognized element: binding.jsonrpc, thats because > Tuscany doesn't have a binding for it so now you need to convert the > binding over to the new Tuscany runtime. There's several bindings to use as > models, the RMI or echo ones are simple, the Axis2 uses the ServletHost > which you'll also need to do: > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.rmi/ > http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/echo.binding/ > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/ > > Copy the existing echo or RMI binding, rename all 'rmi' to jsonrpc', then > try to hook up the JSONRPCEntryPointServlet based on what the Axis2 binding > is doing. You wont need the RMIReference or RMIInvoker classes as jsonrpc > only supports services. > > There's also a binding using DWR instead of json-rpc-java which you port to > the new runtime and its a bit more interesting as it also supports > references (well, externalServices) so you could look at that as well if > you're interested: > http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/. > > If you search back in the dev list archives there's a few mails where we > talk about what these two binding do. > > Hope this helps, > >...ant > > On 8/17/06, Bert Lamb <[EMAIL PROTECTED]> wrote: > > > > On 8/16/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > > > > > In terms of the basic transport, in M1 we had a JSON-RPC binding that > > > supported JSON encoded data over HTTP. We have not got around yet to > > > porting that to the new structure in the trunk. Looking at that would > > > be a good way to dig into how Tuscany works. > > > > > > > I can make an attempt to try and port the jsonrpc binding from M1 over > > to trunk style extensions if this would be appreciated. I agree that > > should help me get an understanding of how some of Tuscany works. > > > > > Oisin may have been referring to how REST would impact the > > > programming model rather than the implementation of bindings. For > > > example, how would cache information in the request be handled by the > > > binding and/or exposed to the application code? What is the mapping > > > between REST resources and SCA services? > > > > > > > Yes, the more I read
Re: REST bindings for Tuscany SCA runtime
What do you think about the following approach: a) If you put no annotations in your code then you have to stick to the fixed pattern with fixed method names, and you write the side SCDL file that turns your code into a component and publishes the REST endpoint. b) If you want more flexibility to map state changes to nicer method names then you use annotations as your were proposing earlier in this thread. The annotations also allow you to completely avoid writing SCDL and specify the details of the binding like the base URI for the resources... Thoughts? These sound like good approaches to me - the one thing that I'm scratching my head about a bit is the create-resource and delete-resource support. The read-resource and update-resource ops are fine, because we have a resource (i.e. the thing that has just been coded). What's implicit here, though, is that there is always a fixed set of resources - the ones that you have just 'deployed'. So the create/delete ops can never be used because things are just set up that way. BTW, this is probably ok and it does match nicely with the accepted admin practice of disabling PUT and DEL in real webservers (as observed previously in this thread). I would be happy enough to leave off the create/delete support for the immediate future :) You have .put and .get in the client example, maybe the .post should be something like customers.post(uri, state-diff) Ah! interesting, I never thought about that before, looks like there could be a pretty good fit with SDO with the following: customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ... This would be an interesting usage of SDO change summaries IMO, obviously just as an option as you should be able to format your state diff in any format you want as long as it's understood by your application. What do you think? This sounds like a nifty fit for sure. But now I have to go and read that SDO spec in more detail, because I know too little about it :) I like the general approach of going down the diff route because if you do it right then you can undo/redo changes to the data, which is neat feature, provided you are willing to store all of the diffs in a timeline. I'll go off and read that spec again. I just love reading specs ;) Are we close enough to condense a summary on the topic of REST and SCA? This would be good white paper material BTW. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Hi Ant, As I am still trying to learn about the REST implementation, based of what you have mentioned below I tried to work on the skeleton classes required for the REST binding on Tuscany, by closely following the REST support in Axis 2 and the Axis2Binding classes in Tuscany. I have created RESTServiceServlet class which does something very similar to what the AxisRESTServlet does in Axis2.Which is processing of GET and POST requests. I however, had a few questions: The Axis2Binding extends from the BindingBuilderExtension which is of the type WebServiceBinding, is it appropriate for the RESTBinding class also to extend the BindingBuilderExtension of the type WebServiceBinding? I am asking this as I have the understanding that REST based service is quite different when compared to a WebService. What should we consider as a RESTService and a RESTReference ?In other words how is a RESTService defined and how should we create one, how are its operations exposed, assuming that we are not using a WSDL as in the case of a Webservice. I appreciate any help in furthering my understanding on this. Thanks. ant elder <[EMAIL PROTECTED]> wrote: Axis2 also has some built in REST support, and as we already have an Axis2 binding it would be relatively easy to get a Tuscany REST binding going using Axis2. All that you need to do is change the Tuscany code to use the Axis2 REST servlet instead of the SOAP one, and change the code where we set up the Axis2 config to set some flags to enable the REST support. With a bit of refactoring of the existing Axis2 binding and changing a few things from private to protected you could probably get something going by subclassing the existing Axis2 binding with minimal new code. I think we should make a better, more 'RESTful' binding than this in the long run, but this approach would be an easy first start. ...ant On 8/22/06, Oisin Hurley wrote: > > > REST is a very generic term, and I think it's more like a resource/ > > service > > naming pattern (URL/URI). When we say REST bindings, what are we > > expecting > > as the REST Service ? > > The resource part is really important, but the small interface part is > important too, as are the expected behaviours of the interface: i.e., > GET is idempotent, PUT will replace a resource, POST will perform a > partial update of the state of a resource. > > IMHO the first place we could go is an XML over HTTP binding and some > kind > of 'generic' processing method in the service (see [0] for an example > of what's RESTful with JAX-WS, which might prompt some ideas). > > cheers > --oh > > [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: REST bindings for Tuscany SCA runtime
The WebServiceBinding and WebServiceBindingLoader classes in the Axis2 binding are WS specific so you'll need to write new ones of those for your REST binding. Your impls should still extend the BindingBuilderExtension and LoaderExtension SPI classes. Also the Axis2BindingBuilder is specific to the WebServiceBinding so you'll need your own version of that. As to what to do about the service and reference questions now that you're not using WSDL and how to define what operations are exposed, there's been various suggestions in this thread. Probably the easiest approach to get going first while using Axis2s REST support would be by using interface.javawith fixed method names for the REST operations (like what Jean-Sebastien suggested?). Later on once you've made some progress and this thread reaches some conclusions you can work with everyone else here on a more comprehensive solution. ...ant Also, fyi, there's a presentation on Axis2 and REST: http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt On 8/24/06, Sreelatha S <[EMAIL PROTECTED]> wrote: Hi Ant, As I am still trying to learn about the REST implementation, based of what you have mentioned below I tried to work on the skeleton classes required for the REST binding on Tuscany, by closely following the REST support in Axis 2 and the Axis2Binding classes in Tuscany. I have created RESTServiceServlet class which does something very similar to what the fdoes in Axis2.Which is processing of GET and POST requests. I however, had a few questions: The Axis2Binding extends from the BindingBuilderExtension which is of the type WebServiceBinding, is it appropriate for the RESTBinding class also to extend the BindingBuilderExtension of the type WebServiceBinding? I am asking this as I have the understanding that REST based service is quite different when compared to a WebService. What should we consider as a RESTService and a RESTReference ?In other words how is a RESTService defined and how should we create one, how are its operations exposed, assuming that we are not using a WSDL as in the case of a Webservice. I appreciate any help in furthering my understanding on this. Thanks. ant elder <[EMAIL PROTECTED]> wrote: Axis2 also has some built in REST support, and as we already have an Axis2 binding it would be relatively easy to get a Tuscany REST binding going using Axis2. All that you need to do is change the Tuscany code to use the Axis2 REST servlet instead of the SOAP one, and change the code where we set up the Axis2 config to set some flags to enable the REST support. With a bit of refactoring of the existing Axis2 binding and changing a few things from private to protected you could probably get something going by subclassing the existing Axis2 binding with minimal new code. I think we should make a better, more 'RESTful' binding than this in the long run, but this approach would be an easy first start. ...ant On 8/22/06, Oisin Hurley wrote: > > > REST is a very generic term, and I think it's more like a resource/ > > service > > naming pattern (URL/URI). When we say REST bindings, what are we > > expecting > > as the REST Service ? > > The resource part is really important, but the small interface part is > important too, as are the expected behaviours of the interface: i.e., > GET is idempotent, PUT will replace a resource, POST will perform a > partial update of the state of a resource. > > IMHO the first place we could go is an XML over HTTP binding and some > kind > of 'generic' processing method in the service (see [0] for an example > of what's RESTful with JAX-WS, which might prompt some ideas). > > cheers > --oh > > [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: REST bindings for Tuscany SCA runtime
Oisin Hurley wrote: What do you think about the following approach: a) If you put no annotations in your code then you have to stick to the fixed pattern with fixed method names, and you write the side SCDL file that turns your code into a component and publishes the REST endpoint. b) If you want more flexibility to map state changes to nicer method names then you use annotations as your were proposing earlier in this thread. The annotations also allow you to completely avoid writing SCDL and specify the details of the binding like the base URI for the resources... Thoughts? These sound like good approaches to me - the one thing that I'm scratching my head about a bit is the create-resource and delete-resource support. The read-resource and update-resource ops are fine, because we have a resource (i.e. the thing that has just been coded). What's implicit here, though, is that there is always a fixed set of resources - the ones that you have just 'deployed'. So the create/delete ops can never be used because things are just set up that way. BTW, this is probably ok and it does match nicely with the accepted admin practice of disabling PUT and DEL in real webservers (as observed previously in this thread). I would be happy enough to leave off the create/delete support for the immediate future :) Oisin, I am not sure I understand the issue with create/delete (except if PUT and DEL are disabled). Posting/putting to a URL that doesn't exist yet to create that resource can be troubling. Is that the issue? Are you looking for some kind of factory service pattern to create resources? Or am I completely mis-understanding the issue you're describing here? :) You have .put and .get in the client example, maybe the .post should be something like customers.post(uri, state-diff) Ah! interesting, I never thought about that before, looks like there could be a pretty good fit with SDO with the following: customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ... This would be an interesting usage of SDO change summaries IMO, obviously just as an option as you should be able to format your state diff in any format you want as long as it's understood by your application. What do you think? This sounds like a nifty fit for sure. But now I have to go and read that SDO spec in more detail, because I know too little about it :) I like the general approach of going down the diff route because if you do it right then you can undo/redo changes to the data, which is neat feature, provided you are willing to store all of the diffs in a timeline. I'll go off and read that spec again. I just love reading specs ;) I don't think that we would mandate the use of SDO change summaries to implement this, support for diffs cannot be SDO specific (IMO the application developer decides what a diff looks like and what he does with it) but we would describe how application code could use SDO to simply implement that approach. Does that make sense? Are we close enough to condense a summary on the topic of REST and SCA? This would be good white paper material BTW. Yes I think it would be great if we could condense this and post it to our Wiki maybe. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
I am not sure I understand the issue with create/delete (except if PUT and DEL are disabled). Posting/putting to a URL that doesn't exist yet to create that resource can be troubling. Is that the issue? Are you looking for some kind of factory service pattern to create resources? Or am I completely mis-understanding the issue you're describing here? :) Apologies for not making the context clearer - however, you've got the point: there needs to be either a resource factory, or a generic resource holder to process create/delete of resources. I think I was attempting to say that a first cut would be ok to support just the GET/POST (as the most pressing scenarios) and then the PUT/DEL and factory approach could follow as a feature improvement. I will put up a wiki summary on this thread. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Oisin Hurley wrote:
I am not sure I understand the issue with create/delete (except if
PUT and DEL are disabled). Posting/putting to a URL that doesn't
exist yet to create that resource can be troubling. Is that the
issue? Are you looking for some kind of factory service pattern to
create resources?
Or am I completely mis-understanding the issue you're describing
here? :)
Apologies for not making the context clearer - however, you've got the
point: there needs to be either a resource factory, or a generic
resource
holder to process create/delete of resources. I think I was attempting
to say that a first cut would be ok to support just the GET/POST (as the
most pressing scenarios) and then the PUT/DEL and factory approach could
follow as a feature improvement.
I will put up a wiki summary on this thread.
cheers
--oh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
I've been struggling myself with the question on whether or not we need
some kind of resource holder/factory to create resources, and I'm now
starting to think that it really depends on how you view your resources.
Just a wild thought here...
If you view your resources as objects, you'll probably say that you need
a factory to do customerFactory->create("http:///customer/1234";).
Then you'll say customers->get("http:///customer/1234";) to retrieve
your customer object.
If on the other hand you view the Web as a giant distributed file
system, then it's not so shocking to say:
customers->createFile("http:///customer1234";);
customers->getFile("http://./customer1234";);
Thoughts?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Oisin Hurley wrote:
>> I am not sure I understand the issue with create/delete (except if
>> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> exist yet to create that resource can be troubling. Is that the
>> issue? Are you looking for some kind of factory service pattern to
>> create resources?
>>
>> Or am I completely mis-understanding the issue you're describing
>> here? :)
>
> Apologies for not making the context clearer - however, you've got the
> point: there needs to be either a resource factory, or a generic
> resource
> holder to process create/delete of resources. I think I was attempting
> to say that a first cut would be ok to support just the GET/POST (as the
> most pressing scenarios) and then the PUT/DEL and factory approach could
> follow as a feature improvement.
>
> I will put up a wiki summary on this thread.
>
> cheers
> --oh
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
I've been struggling myself with the question on whether or not we need
some kind of resource holder/factory to create resources, and I'm now
starting to think that it really depends on how you view your resources.
Just a wild thought here...
If you view your resources as objects, you'll probably say that you need
a factory to do customerFactory->create("http:///customer/1234";).
Then you'll say customers->get("http:///customer/1234";) to retrieve
your customer object.
If on the other hand you view the Web as a giant distributed file
system, then it's not so shocking to say:
customers->createFile("http:///customer1234";);
customers->getFile("http://./customer1234";);
Thoughts?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
It's not clear that there is a difference between customers and
customerFactory in your example. You are saying that there is some resource
that causes the correct interpretation of PUT type requrests
w.r.tgenerating/recording new resources that represent customers. This
resource
itself may, for example, represent the list of customers it has created in
response to GET type requests. The relationship between Customers and
Customer is not a wired relationship in the SCA sense but a resource
relationship as dictated by the URLs used to represent endpoints.
Regards
Simon
Re: REST bindings for Tuscany SCA runtime
Simon Laws wrote:
On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Oisin Hurley wrote:
>> I am not sure I understand the issue with create/delete (except if
>> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> exist yet to create that resource can be troubling. Is that the
>> issue? Are you looking for some kind of factory service pattern to
>> create resources?
>>
>> Or am I completely mis-understanding the issue you're describing
>> here? :)
>
> Apologies for not making the context clearer - however, you've got the
> point: there needs to be either a resource factory, or a generic
> resource
> holder to process create/delete of resources. I think I was attempting
> to say that a first cut would be ok to support just the GET/POST
(as the
> most pressing scenarios) and then the PUT/DEL and factory approach
could
> follow as a feature improvement.
>
> I will put up a wiki summary on this thread.
>
> cheers
> --oh
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
I've been struggling myself with the question on whether or not we need
some kind of resource holder/factory to create resources, and I'm now
starting to think that it really depends on how you view your resources.
Just a wild thought here...
If you view your resources as objects, you'll probably say that you need
a factory to do customerFactory->create("http:///customer/1234";).
Then you'll say customers->get("http:///customer/1234";) to retrieve
your customer object.
If on the other hand you view the Web as a giant distributed file
system, then it's not so shocking to say:
customers->createFile("http:///customer1234";);
customers->getFile("http://./customer1234";);
Thoughts?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
It's not clear that there is a difference between customers and
customerFactory in your example. You are saying that there is some
resource
that causes the correct interpretation of PUT type requrests
w.r.tgenerating/recording new resources that represent customers. This
resource
itself may, for example, represent the list of customers it has
created in
response to GET type requests. The relationship between Customers and
Customer is not a wired relationship in the SCA sense but a resource
relationship as dictated by the URLs used to represent endpoints.
Regards
Simon
Simon,
I agree with what you're saying. I think that we've now closed a loop :)
and that what you're saying is in line with the proposal at the bottom
of http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06704.html
Then we raised the question of whether or not the create verb in
particular should be handled by a separate factory.
And in this last email I was trying to say that somebody coming with an
OO view would probably want that factory separate from the actual
resources (and that I was initially in that camp some time ago), but
that now I'm seeing these resources more like a file system (with no
separate factory) where:
customers.get("http://my.customer.database.com/customers/1234";); returns
an instance of the Customer XSD complex type for customer 1234
customers.put/post("http://my.customer.database.com/customers/1234";,
customerDataObject / or a diff) creates/updates customer 1234 with a
Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
Is that consistent with your view?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
On 9/1/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
> On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Oisin Hurley wrote:
>> >> I am not sure I understand the issue with create/delete (except if
>> >> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> >> exist yet to create that resource can be troubling. Is that the
>> >> issue? Are you looking for some kind of factory service pattern to
>> >> create resources?
>> >>
>> >> Or am I completely mis-understanding the issue you're describing
>> >> here? :)
>> >
>> > Apologies for not making the context clearer - however, you've got
the
>> > point: there needs to be either a resource factory, or a generic
>> > resource
>> > holder to process create/delete of resources. I think I was
attempting
>> > to say that a first cut would be ok to support just the GET/POST
>> (as the
>> > most pressing scenarios) and then the PUT/DEL and factory approach
>> could
>> > follow as a feature improvement.
>> >
>> > I will put up a wiki summary on this thread.
>> >
>> > cheers
>> > --oh
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
>>
>> I've been struggling myself with the question on whether or not we need
>> some kind of resource holder/factory to create resources, and I'm now
>> starting to think that it really depends on how you view your
resources.
>>
>> Just a wild thought here...
>>
>> If you view your resources as objects, you'll probably say that you
need
>> a factory to do customerFactory->create("http:///customer/1234";).
>> Then you'll say customers->get("http:///customer/1234";) to retrieve
>> your customer object.
>>
>> If on the other hand you view the Web as a giant distributed file
>> system, then it's not so shocking to say:
>> customers->createFile("http:///customer1234";);
>> customers->getFile("http://./customer1234";);
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> Hi Sebastien
>
> It's not clear that there is a difference between customers and
> customerFactory in your example. You are saying that there is some
> resource
> that causes the correct interpretation of PUT type requrests
> w.r.tgenerating/recording new resources that represent customers. This
> resource
> itself may, for example, represent the list of customers it has
> created in
> response to GET type requests. The relationship between Customers and
> Customer is not a wired relationship in the SCA sense but a resource
> relationship as dictated by the URLs used to represent endpoints.
>
> Regards
>
> Simon
>
Simon,
I agree with what you're saying. I think that we've now closed a loop :)
and that what you're saying is in line with the proposal at the bottom
of http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06704.html
Then we raised the question of whether or not the create verb in
particular should be handled by a separate factory.
And in this last email I was trying to say that somebody coming with an
OO view would probably want that factory separate from the actual
resources (and that I was initially in that camp some time ago), but
that now I'm seeing these resources more like a file system (with no
separate factory) where:
customers.get("http://my.customer.database.com/customers/1234";); returns
an instance of the Customer XSD complex type for customer 1234
customers.put/post("http://my.customer.database.com/customers/1234";,
customerDataObject / or a diff) creates/updates customer 1234 with a
Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
Is that consistent with your view?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yes, sorry, I wasn't very clear in my post. I'm not trying to go round the
loop again:-) Your summary is consistent with my view.
Assuming HTTP here I probably expect to get different results from
GET - http://my.customer.database.com/customers/ (get me all the
customer records?)
GET - http://my.customer.database.com/customers/1234 (get me one customer
record?)
I'm also probably asking for different things when I say
PUT - http://my.customer.database.com/customers/ (Create all the
customer records?)
PUT - http://my.customer.database.com/customers/1234 (Create one customer
record?)
In normal static HTTP land the semantics are the same in both cases as I'm
just GETing or PUTing data.
In our case what actually happens depends on both the verb and the
Re: REST bindings for Tuscany SCA runtime
Jean-Sebastien Delfino wrote:
Simon Laws wrote:
On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Oisin Hurley wrote:
>> I am not sure I understand the issue with create/delete (except if
>> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> exist yet to create that resource can be troubling. Is that the
>> issue? Are you looking for some kind of factory service pattern to
>> create resources?
>>
>> Or am I completely mis-understanding the issue you're describing
>> here? :)
>
> Apologies for not making the context clearer - however, you've got
the
> point: there needs to be either a resource factory, or a generic
> resource
> holder to process create/delete of resources. I think I was
attempting
> to say that a first cut would be ok to support just the GET/POST
(as the
> most pressing scenarios) and then the PUT/DEL and factory approach
could
> follow as a feature improvement.
>
> I will put up a wiki summary on this thread.
>
> cheers
> --oh
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
I've been struggling myself with the question on whether or not we need
some kind of resource holder/factory to create resources, and I'm now
starting to think that it really depends on how you view your
resources.
Just a wild thought here...
If you view your resources as objects, you'll probably say that you
need
a factory to do customerFactory->create("http:///customer/1234";).
Then you'll say customers->get("http:///customer/1234";) to retrieve
your customer object.
If on the other hand you view the Web as a giant distributed file
system, then it's not so shocking to say:
customers->createFile("http:///customer1234";);
customers->getFile("http://./customer1234";);
Thoughts?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
It's not clear that there is a difference between customers and
customerFactory in your example. You are saying that there is some
resource
that causes the correct interpretation of PUT type requrests
w.r.tgenerating/recording new resources that represent customers. This
resource
itself may, for example, represent the list of customers it has
created in
response to GET type requests. The relationship between Customers and
Customer is not a wired relationship in the SCA sense but a resource
relationship as dictated by the URLs used to represent endpoints.
Regards
Simon
Simon,
I agree with what you're saying. I think that we've now closed a loop
:) and that what you're saying is in line with the proposal at the
bottom of
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06704.html
Then we raised the question of whether or not the create verb in
particular should be handled by a separate factory.
And in this last email I was trying to say that somebody coming with
an OO view would probably want that factory separate from the actual
resources (and that I was initially in that camp some time ago), but
that now I'm seeing these resources more like a file system (with no
separate factory) where:
customers.get("http://my.customer.database.com/customers/1234";);
returns an instance of the Customer XSD complex type for customer 1234
customers.put/post("http://my.customer.database.com/customers/1234";,
customerDataObject / or a diff) creates/updates customer 1234 with a
Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
Is that consistent with your view?
This sounds right to me although I am not sure about the semantics
associated with "post". Also, how might SDO/change history be
integrated into this? Maybe the client has some way to specify the
representation of the resource returned (SDO, YAML, etc) and if it is
SDO then it will include the change summary
--Kevin.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
How are you going with this Sreelatha? Are you still looking at it? Do you need any help, I'd be happy to help if you need anything? Did you see the C++ guys have done something like what we're talking about here now: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED] ...ant On 8/24/06, Sreelatha S <[EMAIL PROTECTED]> wrote: Hi Ant, As I am still trying to learn about the REST implementation, based of what you have mentioned below I tried to work on the skeleton classes required for the REST binding on Tuscany, by closely following the REST support in Axis 2 and the Axis2Binding classes in Tuscany. I have created RESTServiceServlet class which does something very similar to what the AxisRESTServlet does in Axis2.Which is processing of GET and POST requests. I however, had a few questions: The Axis2Binding extends from the BindingBuilderExtension which is of the type WebServiceBinding, is it appropriate for the RESTBinding class also to extend the BindingBuilderExtension of the type WebServiceBinding? I am asking this as I have the understanding that REST based service is quite different when compared to a WebService. What should we consider as a RESTService and a RESTReference ?In other words how is a RESTService defined and how should we create one, how are its operations exposed, assuming that we are not using a WSDL as in the case of a Webservice. I appreciate any help in furthering my understanding on this. Thanks. ant elder <[EMAIL PROTECTED]> wrote: Axis2 also has some built in REST support, and as we already have an Axis2 binding it would be relatively easy to get a Tuscany REST binding going using Axis2. All that you need to do is change the Tuscany code to use the Axis2 REST servlet instead of the SOAP one, and change the code where we set up the Axis2 config to set some flags to enable the REST support. With a bit of refactoring of the existing Axis2 binding and changing a few things from private to protected you could probably get something going by subclassing the existing Axis2 binding with minimal new code. I think we should make a better, more 'RESTful' binding than this in the long run, but this approach would be an easy first start. ...ant On 8/22/06, Oisin Hurley wrote: > > > REST is a very generic term, and I think it's more like a resource/ > > service > > naming pattern (URL/URI). When we say REST bindings, what are we > > expecting > > as the REST Service ? > > The resource part is really important, but the small interface part is > important too, as are the expected behaviours of the interface: i.e., > GET is idempotent, PUT will replace a resource, POST will perform a > partial update of the state of a resource. > > IMHO the first place we could go is an XML over HTTP binding and some > kind > of 'generic' processing method in the service (see [0] for an example > of what's RESTful with JAX-WS, which might prompt some ideas). > > cheers > --oh > > [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: REST bindings for Tuscany SCA runtime
Could you guys also let me know what is the plan for the REST service implementation ? Is anything done on that side ? I'm getting ready to help on implementing the REST service using DAS/SDO if people haven't started yet. Are we going with a customer rest service scenario ? - Luciano On 9/7/06, ant elder <[EMAIL PROTECTED]> wrote: How are you going with this Sreelatha? Are you still looking at it? Do you need any help, I'd be happy to help if you need anything? Did you see the C++ guys have done something like what we're talking about here now: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED] ...ant On 8/24/06, Sreelatha S <[EMAIL PROTECTED]> wrote: > > Hi Ant, > > As I am still trying to learn about the REST implementation, based of > what you have mentioned below I tried to work on the skeleton classes > required for the REST binding on Tuscany, by closely following the REST > support in Axis 2 and the Axis2Binding classes in Tuscany. > I have created RESTServiceServlet class which does something very similar > to what the AxisRESTServlet does in Axis2.Which is processing of GET and > POST requests. > > I however, had a few questions: > > The Axis2Binding extends from the BindingBuilderExtension which is of > the type WebServiceBinding, is it appropriate for the RESTBinding class also > to extend the BindingBuilderExtension of the type WebServiceBinding? I am > asking this as I have the understanding that REST based service is quite > different when compared to a WebService. > What should we consider as a RESTService and a RESTReference ?In other > words how is a RESTService defined and how should we create one, how are its > operations exposed, assuming that we are not using a WSDL as in the case of > a Webservice. > > I appreciate any help in furthering my understanding on this. Thanks. > > ant elder <[EMAIL PROTECTED]> wrote: > Axis2 also has some built in REST support, and as we already have an > Axis2 > binding it would be relatively easy to get a Tuscany REST binding going > using Axis2. All that you need to do is change the Tuscany code to use the > Axis2 REST servlet instead of the SOAP one, and change the code where we > set > up the Axis2 config to set some flags to enable the REST support. With a > bit > of refactoring of the existing Axis2 binding and changing a few things > from > private to protected you could probably get something going by subclassing > the existing Axis2 binding with minimal new code. I think we should make a > better, more 'RESTful' binding than this in the long run, but this > approach > would be an easy first start. > > ...ant > > On 8/22/06, Oisin Hurley wrote: > > > > > REST is a very generic term, and I think it's more like a resource/ > > > service > > > naming pattern (URL/URI). When we say REST bindings, what are we > > > expecting > > > as the REST Service ? > > > > The resource part is really important, but the small interface part is > > important too, as are the expected behaviours of the interface: i.e., > > GET is idempotent, PUT will replace a resource, POST will perform a > > partial update of the state of a resource. > > > > IMHO the first place we could go is an XML over HTTP binding and some > > kind > > of 'generic' processing method in the service (see [0] for an example > > of what's RESTful with JAX-WS, which might prompt some ideas). > > > > cheers > > --oh > > > > [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ > countries) for 2¢/min or less. > -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: REST bindings for Tuscany SCA runtime
I am also interested in helping in this area, but don't have any concrete code or examples to show for it :). I just got back from a bit of vacation and was about to take a look at the REST support in AXIS2 what help it can be. If someone has already put some effort into something though and would like to focus me into being more helpful, just let me know :) -Bert On 9/7/06, Luciano Resende <[EMAIL PROTECTED]> wrote: Could you guys also let me know what is the plan for the REST service implementation ? Is anything done on that side ? I'm getting ready to help on implementing the REST service using DAS/SDO if people haven't started yet. Are we going with a customer rest service scenario ? - Luciano On 9/7/06, ant elder <[EMAIL PROTECTED]> wrote: > > How are you going with this Sreelatha? Are you still looking at it? Do you > need any help, I'd be happy to help if you need anything? Did you see the > C++ guys have done something like what we're talking about here now: > > > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED] > >...ant > > On 8/24/06, Sreelatha S <[EMAIL PROTECTED]> wrote: > > > > Hi Ant, > > > > As I am still trying to learn about the REST implementation, based of > > what you have mentioned below I tried to work on the skeleton classes > > required for the REST binding on Tuscany, by closely following the REST > > support in Axis 2 and the Axis2Binding classes in Tuscany. > > I have created RESTServiceServlet class which does something very > similar > > to what the AxisRESTServlet does in Axis2.Which is processing of GET and > > POST requests. > > > > I however, had a few questions: > > > > The Axis2Binding extends from the BindingBuilderExtension which is of > > the type WebServiceBinding, is it appropriate for the RESTBinding class > also > > to extend the BindingBuilderExtension of the type WebServiceBinding? I > am > > asking this as I have the understanding that REST based service is quite > > different when compared to a WebService. > > What should we consider as a RESTService and a RESTReference ?In other > > words how is a RESTService defined and how should we create one, how are > its > > operations exposed, assuming that we are not using a WSDL as in the case > of > > a Webservice. > > > > I appreciate any help in furthering my understanding on this. Thanks. > > > > ant elder <[EMAIL PROTECTED]> wrote: > > Axis2 also has some built in REST support, and as we already have an > > Axis2 > > binding it would be relatively easy to get a Tuscany REST binding going > > using Axis2. All that you need to do is change the Tuscany code to use > the > > Axis2 REST servlet instead of the SOAP one, and change the code where we > > set > > up the Axis2 config to set some flags to enable the REST support. With a > > bit > > of refactoring of the existing Axis2 binding and changing a few things > > from > > private to protected you could probably get something going by > subclassing > > the existing Axis2 binding with minimal new code. I think we should make > a > > better, more 'RESTful' binding than this in the long run, but this > > approach > > would be an easy first start. > > > > ...ant > > > > On 8/22/06, Oisin Hurley wrote: > > > > > > > REST is a very generic term, and I think it's more like a resource/ > > > > service > > > > naming pattern (URL/URI). When we say REST bindings, what are we > > > > expecting > > > > as the REST Service ? > > > > > > The resource part is really important, but the small interface part is > > > important too, as are the expected behaviours of the interface: i.e., > > > GET is idempotent, PUT will replace a resource, POST will perform a > > > partial update of the state of a resource. > > > > > > IMHO the first place we could go is an XML over HTTP binding and some > > > kind > > > of 'generic' processing method in the service (see [0] for an example > > > of what's RESTful with JAX-WS, which might prompt some ideas). > > > > > > cheers > > > --oh > > > > > > [0] > http://java.sun.com/developer/technicalArticles/WebServices/restful/ > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ > > countries) for 2¢/min or less. > > > > -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: REST bindings for Tuscany SCA runtime
Hi Ant, I aplologize for the delayed response. I am stuck with some other work and am neck deep into it right now. I would not be able to look any further into this. Could somebody else please take this forward. Thanks. Bert Lamb <[EMAIL PROTECTED]> wrote: I am also interested in helping in this area, but don't have any concrete code or examples to show for it :). I just got back from a bit of vacation and was about to take a look at the REST support in AXIS2 what help it can be. If someone has already put some effort into something though and would like to focus me into being more helpful, just let me know :) -Bert On 9/7/06, Luciano Resende wrote: > Could you guys also let me know what is the plan for the REST service > implementation ? Is anything done on that side ? I'm getting ready to help > on implementing the REST service using DAS/SDO if people haven't started > yet. Are we going with a customer rest service scenario ? > > - Luciano > > On 9/7/06, ant elder wrote: > > > > How are you going with this Sreelatha? Are you still looking at it? Do you > > need any help, I'd be happy to help if you need anything? Did you see the > > C++ guys have done something like what we're talking about here now: > > > > > > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL > > PROTECTED] > > > > ...ant > > > > On 8/24/06, Sreelatha S wrote: > > > > > > Hi Ant, > > > > > > As I am still trying to learn about the REST implementation, based of > > > what you have mentioned below I tried to work on the skeleton classes > > > required for the REST binding on Tuscany, by closely following the REST > > > support in Axis 2 and the Axis2Binding classes in Tuscany. > > > I have created RESTServiceServlet class which does something very > > similar > > > to what the AxisRESTServlet does in Axis2.Which is processing of GET and > > > POST requests. > > > > > > I however, had a few questions: > > > > > > The Axis2Binding extends from the BindingBuilderExtension which is of > > > the type WebServiceBinding, is it appropriate for the RESTBinding class > > also > > > to extend the BindingBuilderExtension of the type WebServiceBinding? I > > am > > > asking this as I have the understanding that REST based service is quite > > > different when compared to a WebService. > > > What should we consider as a RESTService and a RESTReference ?In other > > > words how is a RESTService defined and how should we create one, how are > > its > > > operations exposed, assuming that we are not using a WSDL as in the case > > of > > > a Webservice. > > > > > > I appreciate any help in furthering my understanding on this. Thanks. > > > > > > ant elder wrote: > > > Axis2 also has some built in REST support, and as we already have an > > > Axis2 > > > binding it would be relatively easy to get a Tuscany REST binding going > > > using Axis2. All that you need to do is change the Tuscany code to use > > the > > > Axis2 REST servlet instead of the SOAP one, and change the code where we > > > set > > > up the Axis2 config to set some flags to enable the REST support. With a > > > bit > > > of refactoring of the existing Axis2 binding and changing a few things > > > from > > > private to protected you could probably get something going by > > subclassing > > > the existing Axis2 binding with minimal new code. I think we should make > > a > > > better, more 'RESTful' binding than this in the long run, but this > > > approach > > > would be an easy first start. > > > > > > ...ant > > > > > > On 8/22/06, Oisin Hurley wrote: > > > > > > > > > REST is a very generic term, and I think it's more like a resource/ > > > > > service > > > > > naming pattern (URL/URI). When we say REST bindings, what are we > > > > > expecting > > > > > as the REST Service ? > > > > > > > > The resource part is really important, but the small interface part is > > > > important too, as are the expected behaviours of the interface: i.e., > > > > GET is idempotent, PUT will replace a resource, POST will perform a > > > > partial update of the state of a resource. > > > > > > > > IMHO the first place we could go is an XML over HTTP binding and some > > > > kind > > > > of 'generic' processing method in the service (see [0] for an example > > > > of what's RESTful with JAX-WS, which might prompt some ideas). > > > > > > > > cheers > > > > --oh > > > > > > > > [0] > > http://java.sun.com/developer/technicalArticles/WebServices/restful/ > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > - > > > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ > > > countries) for 2¢/min or less. > > > > > > > > > > -- > - > Luciano Resende > SOA Opensource - Apache Tusc
