Dear Shawn Dahlen,
Thanks a lot for your input. Since your concerns are
at a very fundamental level why not put them into a
diagram? That way it would be a lot easier to
understand and discuss. Just try to explain with
arrows and boxes how the engine should work IYO. A
small engine toy would be nice too:)
I don't see lot of differences b/w your idea's and
those of axis2 developers.
Any chance of u making it to the f2f?
--Dasarath
--- Shawn Dahlen <[EMAIL PROTECTED]> wrote:
> 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
=== message truncated ===
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
