You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Shawn Dahlen <sm...@gmail.com> on 2005/02/27 23:05:31 UTC
[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
Re: [Axis 2] Messaging and Service Models
Posted by Shawn Dahlen <sm...@gmail.com>.
Apologies for the wrong subject prefix.
On Sun, 27 Feb 2005 17:05:31 -0500, Shawn Dahlen <sm...@gmail.com> 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 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
>
Re: [Axis 2] Messaging and Service Models
Posted by 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
Re: [PRIVATE] Re: [Axis 2] Messaging and Service Models
Posted by 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
> >
>
>
Re: [Axis 2] Messaging and Service Models
Posted by Dasarath Weeratunge <da...@yahoo.com>.
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 <sm...@gmail.com> 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