Re: [PRIVATE] Re: [Axis 2] Messaging and Service Models

[Shawn Dahlen <sm...@gmail.com>]

Sanjiva -

Thank you for the comments. I apologize for the late response.  I will
attempt to respond in full tonight when I arrive at my hotel.  I
certainly want to collaborative with all of you on the Axis 2 design. 
I am currently looking into funding options to make it to the
conference at the end of March, and I should know within a few days. 
At the very least, could I teleconference if that were feasible?  I
understand that communicating in person especially over issues of
design will certainly expediate the implementation :)

Thanks -

Shawn


On Mon, 28 Feb 2005 09:51:37 +0600, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> Hi Shawn,
> 
> Outstanding comments; thank you! I will reply to them publicly
> shortly.
> 
> Is there any chance you can make it to the Axis2 F2F we're
> organizing for March 29th-31st here in Colombo, Sri Lanka?
> I think that would be a great way to drive these things
> through ...
> 
> Sanjiva.
> 
> ----- Original Message -----
> From: "Shawn Dahlen" <sm...@gmail.com>
> To: <ax...@ws.apache.org>
> Sent: Monday, February 28, 2005 4:05 AM
> Subject: [Axis 2] Messaging and Service Models
> 
> > Axis 2 Developers -
> >
> > I have spent the last month and a half lurking on the mailing list and
> > perusing the code base for Axis 2.  I recently posted a few comments
> > in the "Dig Into Axis 2" thread, and I would like to expand upon some
> > ideas in this email.  In particular, I have a great interest in the
> > creation of a web services framework that supports a low-level
> > messaging model, and I have been looking at the Axis 2 project as the
> > deliverer for this.  In the rest of this email, I will present my
> > areas of interest within the Axis 2 project, and some concepts that I
> > have been brainstorming regarding the code base.  Feedback is most
> > welcomed by the developer community, and if the comments are favorable
> > I would be happy to participate in the implementation.  At the very
> > least, I imagine that my concepts could provide a healthy debate
> > leading towards a better product in the long-term.
> >
> > 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).  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.
> >
> > It is my intent to see that Axis 2 provides a simple and elegant
> > programming model that may be leveraged by IT applications and systems
> > requiring integration following service-oriented principles.
> >
> > 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.  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.
> >
> >  The "MessageProducer" class would support a single operation, send(),
> > that would accept a SOAP message and send it one way to a given
> > EndpointReference (traversing through the engine pipeline first).
> >
> > The "MessageEndpoint" class would extend the "Endpoint" class (which I
> > will discuss more about briefly), and provide a single operation
> > called receive(), accepting a SOAP message.  The application that
> > creates such an endpoint must associate a URI and register it with the
> > Axis framework so it in turn may listen on the appropriate port (for a
> > given transport protocol).
> >
> > The "MessageClient" class extends "MessageProducer" offering a set of
> > methods that capture basic MEPs.  Its implementation is
> > straightforward, leveraging the lower-level messaging model.  I have
> > provided some pseudo-code below implementing sendReceiveAsync() using
> > an asynchronous transport:
> >
> > public class MessageClient extends MessageProducer
> > {
> >   public void sendReceiveAsync(SOAPEnvelope env, Callback callback) {
> >     final long messageID = System.currentTimeMillis();
> >     final Correlator correlator = Correlator.getInstance();
> >
> >     // this is only required if the transport is not bi-directional
> otherwise
> >     // we can listen on the 'back channel'; as such the replyTo header
> should
> >     // be set to anonymous --> use invoker to wait for results (note:
> > not shown belown)
> >
> >     // creates anonymous listener endpoint
> >     MessageEndpoint endpoint = new MessageEndpoint() {
> >       public void receive(SOAPEnvelope env) {
> >         RelatesTo relatesTo = env.getAddressingHeaders().getRelatesTo();
> >         Callback callback =
> correlator.getCorrelationInfo(relatesTo.getAddress(\
> > ));
> >
> >         AsyncResult result = new AsyncResult();
> >         result.setResult(env);
> >         callback.setComplete(true);
> >         callback.setResult(result);
> >         callback.doComplete();
> >
> >
> EndpointRegistry.remove(env.getAddressHeaders().getTo().getAddress());
> >       }
> >     };
> >
> >     // registers endpoint listener
> >     // please note that the EndpointRegistry is a concept and could be
> > implemented in the
> >     // Axis Engine itself
> >     EndpointReference replyTo = getAddressingHeaders().getReplyTo();
> >     EndpointRegistry.add(replyTo.getAddress(), endpoint);
> >
> >     // add correlation info
> >     correlator.setCorrelationInfo(messageID, callback);
> >
> >     send(env);
> > }
> >
> > With the axis engine core, the object model, and the messaging package
> > (along with some transport implementations), I could create a web
> > services messaging system where each application embeds Axis for its
> > SOAP communication stack for integration purposes.
> >
> > Once the messaging model has been established, we can introduce a
> > higher-level service model.  A service endpoint is self-describing
> > (using a service description language such as WSDL or perhaps Savis'
> > SSDL).  It acts upon a set of actions (described within a message),
> > and may return a result.  As such, it differs from a message endpoint
> > because it may have both a request and response channel (handler
> > flow).  However, this request/response viewpoint is purely artificial,
> > and in fact may be built using the in-channel of an "endpoint" and the
> > out-channel of a message producer.
> >
> > The service programming model should allow for the following features:
> > - code generation of interface and messages through a service
> > description (WSDL, SSDL)
> > - provide an *event-driven* and/or blocking interface (i think this is BIG
> :) )
> > - provide wrapped or unwrapped method signatures
> > - support annontations to specify modules and runtime behavior
> > (override in config files; this should be offered in generic message
> > endpoints as well)
> > - support pluggable OX binding technologies
> >
> > Instead of the current "Dispatcher", I recommend that we introduce a
> > "EndpointRouter".  This handler would be responsible for locating an
> > "Endpoint" implementation based in the wsa:To property, adding its
> > specific phases to the chain, as well as the implementation class.
> >
> > An "Endpoint" is a simple maker interface that extends Handler.  There
> > exists two types of endpoints, a "MessageEndpoint" and a
> > "ServiceEndpoint", supporting both programming models.  The
> > "MessageEndpoint" provides an abstract receive() method that
> > individuals can override if they want a low-level messaging solution.
> > This low-level solution offers no support for action dispatching based
> > on wsa:Action, therefore a switch statement might be needed.  The
> > "ServiceEndpoint" on the otherhand is represented by a service
> > description document (WSDL or SSDL), and offers action dispatching to
> > a particular method call.  The "ServiceEndpoint" would enlist the help
> > of a "Provider" implementation to actually invoke a piece of logic.
> > If a response is required, the "ServiceEndpoint" would use a
> > "MessageProducer" to send the message to the appropriate party.
> >
> > In the end, an endpoint consume messages, and a producer sends
> > messages.  We can build all of the MEPs on top of those two concepts.
> >
> > I apologize for the long-winded email.  My intent was to introduce
> > some of my brainstorming with regards to the two programming models,
> > and elicit some feedback.  I will start implementing the low-level
> > messaging model (since a line of code is worth a thousand words), and
> > would love to work in collaboration with all of you, if you find my
> > comments favorable.  I will be attending the ServerSide Symposium this
> > week, and if any of you will be attending let me know.
> >
> > Thank you for your time,
> >
> > Shawn Dahlen
> >
> 
>