Sanjiva -
Here are some of my additional comments. I apologize if they are not
polished. I'm in the middle of a conference, and could not prepare
myself better ;) :
1. I believe the integration style of messaging is more applicable to
large-scale distributed computing, and hence have been pushing within
my own team the web services messaging perspective (ws-messaging :))
In fact, the new ws-messaging specs will offer interoperability with
messaging systems, much like SOAP and WSDL did for distributed object
platforms. As such, I have been approaching design leveraging
messaging terminology, both from the book Enterprise Integration
Pattern, and the Web Services Architecture Note. Essentially, like
you stated, Axis 2 is a pipes and filter architecture built on
concepts such as a messages, pipelines, filters, transports, and
endpoints. I hope this clarifies where some of my terminology has
roots in (and I understand where Axis 2 terminology has come from).
2. Srinath mentioned in a seperate thread about creating Transport
modules. I think this is a great idea especially if those modules are
pluggable. In the psedo-code I presented earlier, endpoints must be
registered with an "EndpointRegistry". The EndpointRegistry would
determine if a given transport protocol was indeed running on the
desired port. If not, we would need some pluggable way to lookup the
"TransportServer" and instantiate it, so messages could be recieved
for the endpoint. In my mind, this is all hidden from the end user.
They just enter the URI for the endpoint when registering and
everything else is taken care of. A few questions (for all) regarding
transports:
- How does one select which transport protocol to use, especially if
you consider that SOAP and the WS-Messaging engine supports all the
QoS that gave purpose to a given transport?
- As a consequence, is the requirement of protocol independence
broken? Perhaps, but SOAP can deliver QoS (reliability, transactions,
security, etc) that the REST movement cannot.
3. You also mentioned that endpoints should just receive the the
message payload, and as a consequence find some common ground with the
REST movement. I certainly am up for accomplishing this. However, I
would stress that a given endpoint (at a low level -- MessageEndpoint)
may need access to the reply address so it can create a
MessageProducer and send a response. I would love hear more of your
thoughts on this matter.
4. Srinath mentioned that the receiver concept was similar to what I
was proposing. Perhaps I do not understand its purpose, but why do we
want to capture a MEP in a handler? Isn't the MEP (irregard of a WSDL
description) driven by message endpoints, especially if everything is
inheritently one-way in messaging? Wouldn't the Call (or
MessageClient) class drive the exchange pattern? I would love to talk
further on this, I might be at a loss for what you guys were hoping to
do.
5. One issue I have been struggling with is how to configure an output
pipeline for a MessageProducer. Microsoft's WSE 2.0 from my
understanding only supports global handlers (filters). A few
brainstorming thoughts: Should we lookup the output pipeline based on
the endpoint destination? Are the required handlers for sending a
message determine by the policy (and features) of the consumer
endpoint? I will continue to think about this issue. Thoughts from
you?
6. Srinath was correct that I should put together some diagrams and a
toy engine, and I hope to have something ready by the conference
(still waiting on an OK to go). I would recommend for anyone
interested in my perspective to simply look at WSE 2.0 and browse
through the Enterprise Intergration Patterns book.
Thanks -
Shawn Dahlen
On Mon, 28 Feb 2005 20:57:55 +0600, Sanjiva Weerawarana
<[EMAIL PROTECTED]> wrote:
> Hi Shawn,
>
> > > > 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.
>
> Yep absolutely. Thanks for your thoughts!
>
> > > > 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
>
> +1.
>
> > > > 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.
>
> Yep.
>
> > > > 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.
>
> +1.
>
> > > > 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.
>
> I agree the "Call" API is too suggestive of client-server stuff and
> should probably be renamed at least for the lowest level. Unless
> I missed something subtle I believe many of the changes you are
> suggesting are fairly straightforward and +1'able.
>
> > > > 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).
>
> OK.
>
> > > > 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());
> > > > }
> > > > };
>
> I like this approach!
>
> > > > // 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.
>
> Yep! My one additional constraint is that the programming model
> should only allow the app to see the payload. That is, any
> SOAP headers etc. are "middleware" stuff which is involved
> with delivering that bit of XML to the application.
>
> The beauty of that approach is that we can merge REST and WS-*
> stuff with that. That is, the same "service" implementation
> can be dropped a bit of XML which is carried just in the HTTP
> POST body or within the soap:Body element. The difference of
> course is that if its within soap:Body then the message can be
> delivered at higher qualities of service that the vanilla HTTP
> message can.
>
> I have no objection to having a PM that makes the whole SOAP
> envelope visible too. In fact, we already do - that's basically
> what handlers are.
>
> > > > 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
>
> Sure .. I believe all of those are Axis2 design objectives already!
>
> > > > 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.
>
> Terminology again?
>
> > > > 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 do like the Endpoint terminology .. actually IIRC Paul Fremantle
> was suggesting something like this at the first F2F but we didn't
> pursue that much then.
>
> > > > 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.
>
> Absolutely. What would be *ideal* is if you could come to the Axis2
> F2F .. we could thrash these out and come up with ways to go forward!
>
> Thanks again for the detailed thoughts!
>
> Sanjiva.
>
>
