WS-Addressing Implementation

[Davanum Srinivas <di...@yahoo.com>]

FYI, http://ws.apache.org/ws-fx/addressing/

-- dims

=====
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: WS-Addressing Implementation

[Steve Loughran <st...@iseran.com>]

Anne Thomas Manes wrote:
> Perhaps it is a break from REST, but it isn't a break from the core SOAP 
> architecture -- which as a message packaging protocol is designed to be 
> completely independent from the underlying transport. (and we all should 
> admit that SOAP uses HTTP as a transport, not as a transfer protocol)
> 
> The SOAPAction parameter may be RESTful, but it isn't SOAPy. Message 
> routing should not rely on any transport-specific parameters. (How can 
> you specify the SOAPAction when using JMS, SMTP, FTP, or Jabber as a 
> transport?)
> 


> The W3C WS teams have spent quite a bit of time and effort to make sure 
> that Web services operate as good RESTful citizens, but SOAP is based on 
> an SOA architecture rather than a REST architecture. (Its focus is on 
> services rather than resources and state) There are times when the two 
> architectures clash.

Web services are now based on resources and state, at least according to 
last week's press releases.

> 
> The true power of SOAP is derived from the SOAP processing model -- not 
> from its ability to send and receive messages to a specific URL. A 
> resource always exists at a specific URL. Services are more abstract 
> than resources -- it could be that you might have a number of resources 
> that cooperate in providing the service. You can redirect the URL, but 
> redirection isn't an especially dynamic, policy-driven process. The Web 
> services architecture requires a more dynamic mechanism to route requests.

Some uses of it do, certainly, even if by adopting asynchronous 
messaging you lose (without time bounded comms) the ability to achieve, 
in formal terms, agreement or common knowlege.

 > WS-Addressing enables support for asynchronous
> computing, content-based routing, version management, load balancing, 
> and other capabilities.


1. I can have different versions of a service at different URLS. that is 
what DNS is for. That is also what UDDI was nominally for.

2. content based routing. hmmm.

3. its a lot easier to load balance based on the URL

Essentially SOAP messages implement the command pattern (GoF 223). You 
send a document containing the command. The command may be explicit in 
the action, or it may be implicit in the type of the body of the message 
itself.

often we forget this with our XML-doc-to-objects-and-method code binding 
tools, be they Axis or something else, but essentially an endpoint is 
receiving documents that hint what they want done, either explictly or 
implicitly. We are already doing content based routing, it just happens 
to be routing to classes and methods in the same JVM, and the fact that 
this is taking place is hidden.

But I could do more explicit routing of incoming messages if I wanted 
to, today.

What ws-addressing does do is permit explicit store-and-forward 
communications. It also enables the complete abandonment of HTTP as an 
underlying infrastructure. does that make it a good thing? I dont know. 
i quite like fact that HTTP and SOAP are mixed, as some other people 
used to think: 
http://msdn.microsoft.com/msdnmag/issues/0300/soap/default.aspx

-Steve

Re: WS-Addressing Implementation

[Anne Thomas Manes <an...@manes.net>]

Perhaps it is a break from REST, but it isn't a break from the core SOAP 
architecture -- which as a message packaging protocol is designed to be 
completely independent from the underlying transport. (and we all should 
admit that SOAP uses HTTP as a transport, not as a transfer protocol)

The SOAPAction parameter may be RESTful, but it isn't SOAPy. Message 
routing should not rely on any transport-specific parameters. (How can you 
specify the SOAPAction when using JMS, SMTP, FTP, or Jabber as a transport?)

The W3C WS teams have spent quite a bit of time and effort to make sure 
that Web services operate as good RESTful citizens, but SOAP is based on an 
SOA architecture rather than a REST architecture. (Its focus is on services 
rather than resources and state) There are times when the two architectures 
clash.

The true power of SOAP is derived from the SOAP processing model -- not 
from its ability to send and receive messages to a specific URL. A resource 
always exists at a specific URL. Services are more abstract than resources 
-- it could be that you might have a number of resources that cooperate in 
providing the service. You can redirect the URL, but redirection isn't an 
especially dynamic, policy-driven process. The Web services architecture 
requires a more dynamic mechanism to route requests.

The SOAP processing model supports the two powerful and important features:
- clean separation of message packaging model from the transport mechanism
- clean separation of system-level information from application payload

The problem is that until recently, product implementations really haven't 
given us the ability to exploit the power of these features. WS-Addressing 
is perhaps the most important specification in our arsenal. It gives us the 
ability to control the routing of messages, and it truly enables the first 
of these two features. (It is enabled by the second features.) 
WS-Addressing enables support for asynchronous computing, content-based 
routing, version management, load balancing, and other capabilities.

Anne

At 03:25 AM 2/12/2004, you wrote:
>Ias wrote:
>>>FYI, http://ws.apache.org/ws-fx/addressing/
>>Thanks very much for your nice work!
>>Hoping Apache Addressing's thriving future with interest and participation
>>from people everywhere,
>
>While I am glad that we are keeping up with the WS-* standards, I am 
>unsure about the whole sub-addressing feature of WS addressing (or 
>alternate proposals), that essentially add a new destination to a endpoint 
>above and beyond the current (url,SOAPAction) tuple. Now every header can 
>take a ws-addressing address and use that to redirect the message.
>
>That may let you tack on more stuff to the same endpoint, but at the same 
>time the nice and simple notion of "one url, one service" is lost. It 
>almost represents the complete divorce of WS-* from the REST architecture.
>
>Thank you for the code though Dims! I will be using it in 
>WS-ResourceFramework related stuff :)

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group 

Re: WS-Addressing Implementation

[Steve Loughran <st...@iseran.com>]

Davanum Srinivas wrote:
> We all have our pet peeve's and skeletons we'd like to bury :)

Well, I think that ws-* is aggressively diverging from REST, and despite 
attempts by SOAP1.2 to bring the two architectures together, it aint 
happening.


> Do you want to work on WS-Resource* on ws-fx as well? I was thinking of taking a stab at either
> WS-Eventing or WS-Notification soon.
> 

heh. no. Ask Glen :)

Actually, if you are going to do any of them, ws-eventing is a lot, lot 
simpler. ws-notification scares me.

Re: WS-Addressing Implementation

[Davanum Srinivas <di...@yahoo.com>]

We all have our pet peeve's and skeletons we'd like to bury :)

Do you want to work on WS-Resource* on ws-fx as well? I was thinking of taking a stab at either
WS-Eventing or WS-Notification soon.

thanks,
dims

--- Steve Loughran <st...@iseran.com> wrote:
> Ias wrote:
> >>FYI, http://ws.apache.org/ws-fx/addressing/
> > 
> > Thanks very much for your nice work!
> > 
> > Hoping Apache Addressing's thriving future with interest and participation
> > from people everywhere,
> > 
> 
> While I am glad that we are keeping up with the WS-* standards, I am 
> unsure about the whole sub-addressing feature of WS addressing (or 
> alternate proposals), that essentially add a new destination to a 
> endpoint above and beyond the current (url,SOAPAction) tuple. Now every 
> header can take a ws-addressing address and use that to redirect the 
> message.
> 
> That may let you tack on more stuff to the same endpoint, but at the 
> same time the nice and simple notion of "one url, one service" is lost. 
> It almost represents the complete divorce of WS-* from the REST 
> architecture.
> 
> Thank you for the code though Dims! I will be using it in 
> WS-ResourceFramework related stuff :)
> 


=====
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: WS-Addressing Implementation

[Steve Loughran <st...@iseran.com>]

Ias wrote:
>>FYI, http://ws.apache.org/ws-fx/addressing/
> 
> Thanks very much for your nice work!
> 
> Hoping Apache Addressing's thriving future with interest and participation
> from people everywhere,
> 

While I am glad that we are keeping up with the WS-* standards, I am 
unsure about the whole sub-addressing feature of WS addressing (or 
alternate proposals), that essentially add a new destination to a 
endpoint above and beyond the current (url,SOAPAction) tuple. Now every 
header can take a ws-addressing address and use that to redirect the 
message.

That may let you tack on more stuff to the same endpoint, but at the 
same time the nice and simple notion of "one url, one service" is lost. 
It almost represents the complete divorce of WS-* from the REST 
architecture.

Thank you for the code though Dims! I will be using it in 
WS-ResourceFramework related stuff :)

RE: WS-Addressing Implementation

[Ias <ia...@tmax.co.kr>]

> FYI, http://ws.apache.org/ws-fx/addressing/
Thanks very much for your nice work!

Hoping Apache Addressing's thriving future with interest and participation
from people everywhere,

Ias

> 
> -- dims
> 
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
>