Re: [Axis 2] Messaging and Service Models

[Srinath Perera <he...@gmail.com>]

Hi Shawn;
Thanks for the the great comments, If you can make it to SL (see the
mail at axis dev with Re: [axis2] organizing a 2nd face-to-face
meeting - DATES: March 29th to 31st (inclusive)) for the F2F that
would be great!

I Belive we (axis2 team and you ) are not much apart in the design,
where as you take the next step to and try make  does not assume the
client and Server roles. To MHO  the design Axis2 end up and the
design you purposed  is quite close

> It is clear that the Axis developer community supports the notion that
> asynchronous messaging has vaulted to forefront of web services
> architecture.  I believe I am correct in assuming that Axis 2 aims to
> be a web services framework supporting the asynchronous exchange of
> SOAP messages in which these messages may be combined into a variety
> of exchange patterns (some of which may be defined by a service
> description language such as WSDL).  
Aixs2 aim to design a core that does not assume the neither Sync nor
async behaviour. To MHO It is not implementing *Sync over Async* nor
"Async over Sync"
>In addition to supporting the
> exchange of messages, Axis also offers a "Pipes and Filter"
> architecture implemented as the Axis Engine defining a configurable
> set of SOAP intermediaries (WS-RM, WS-Security, etc) for a specified
> endpoint.
this is handlers :)?


> It is my belief that Axis should support two programming models based
> off of the W3C Web Services Architecture Note.  The first model should
> be a low-level messaging model solely focused on asynchronously
> sending or receiving a SOAP message.  This model should make no
> assumptions regarding a particular topology (i.e. it should support
> peer-to-peer and a client/server).  From my perspective, when systems
> integrate through messaging, they act as peers, switching between the
> roles of a producer and a consumer.  With the creation of such a
> model, all other MEPs may be constructed on top of it. 
+1 one for not assuming a topology, 

> As such, I humbly request the introduction of a "messaging" package that would
> contain a "MessageProducer", a "MessageEndpoint", the SOAP envelope
> classes, and potentially the WS-Addressing implementation (since web
> service messaging is dependent on it).  In addition to these low-level
> classes, another class, "MessageClient" may be introduced representing
> the interface currently adorning the Call class (built leveraging the
> MessageProducer and MessageEndpoint classes).  This package should
> replace the current "clientapi" package that is closely tied to a
> client/server topology.   A fine example of this low-level messaging
> approach has been implemented in Microsoft's WSE 2.0.
I see MessageProducer as a more abstract layrer for the Sending
messages, But important thing Shawn take up is to use this same
interface from the Server as well as the client side which is a cool
idea

The Message Endpoints are quite similer to recivers .. they handle the
MEPS and the Sync Async behaviour and use the proivders to invoke the
the Businuss logic as approprivate and start a reply if it is there!

send() and recive() methods you mentioned are now implemented via
AxisEngine send() recive() methods. The Dispatcher now does locating
the service based on the Addressing To header as you purposed.

Let me generalise (accepting the risk of mistinterpeting)
I belive we both have a designs that is quite similer .. (most
compoenets in the each can found the counterparts in the other ).
Sahwn direct our attention  to the follwing

1) message sending core that does not assume the client server
bahaviours which can be used by server side and client side.
2) message reciving core that consists of ServiceEndpoints (this
matches to Recivers now ..IMO the ServiceEndpoint is a better name for
Recivers :) ) that handle the MEPS and sync Async bahaviour and
MessageEndpoints that handles each message level processing

I think we have some terminology to take care of ..but to MHO the
changes  purposed can be apllied and will undoubtfully improve our
message processing model
Thanks
Srinath