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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
snip
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.
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
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]
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
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
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
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
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
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]
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
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
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
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
35 matches
Mail list logo
