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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > To: <[email protected]> > 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 > > > >
