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/03/03 17:03:29 UTC
Re: [Axis2] Fw: [Axis 2] Messaging and Service Models
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
<sa...@opensource.lk> 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.
>
>
Re: [Axis 2] async/messaging API?
Posted by Shawn Dahlen <sm...@gmail.com>.
> >
> i personally would like to use util.concurrent.Future
> (java.util.concurrent.Future in JDK5 backported to JDK 1.4
> http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) in API
> to denote delayed result such as async response message in MEP
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html
> that is used for example in JBoss (though i think that API is overly
> complex mix of homegrown async and EJB):
> http://docs.jboss.org/ejb3/tutorial/asynch/asynch.html
I looked into the use of Future recently in JDK5, but I didn't know that
it was backported. I think it would be wise to at least look into for the
async capabilities.
> it is still better than dealing with callbacks IMHO:
> http://www.onjava.com/pub/a/onjava/2005/02/23/remoting.html
>
> and then there are some other interesting ideas mostly around metadata
> annotations like this one:
> http://jroller.com/page/talipozturk/20050117#asynchronous_methods_in_java
Has anyone done research into the potential projects that may offer
code annotations
in JDK 1.4? I think this will have some importance as we attempt to
simplify the
programming model. I know of Apache Attributes.
[Axis 2] async/messaging API?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Chathura Herath wrote:
>>>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?
>>>
>>>
>
>To my understanding MEP doesn't say anything about whether the service is
>sync/async and if I'm right that is a user decision which says how the
>client will behave after sending the out message and till the reception of
>the in message. Similar argument is valid for the server side. This get
>fussier due to the usage of the Transport being oneway/twoway(e.g. Http is a
>two way transport and would require a response in the transport level
>despite the service call being sync/async).
>So three things to note are
>1) MEP
>2) sync/async behavior of the service
>3) behavior of the transport.
>
>Axis2 was architected with Asynchronous in mind, but Synchronous ws calls
>were of great significance. So the receiver concept is expected to
>differentiate the behavior of the message path inside the engine which will
>be determined based on the MEP in the WSDL and service being a sync/async.
>Further the transport layer complexity will be handled inside the
>TransportReceiver s and TransportSender s.
>
>
>
>>>Wouldn't the Call (or
>>>MessageClient) class drive the exchange pattern?
>>>
>>>
>
>Not right now in Axis2. If you look at the Call class you ll see that it
>provides a generic API so that client Stub can use Call and invoke the
>*right method* to get the expected behavior (Sync/Async and MEP). Basically
>we will eventually codegen a client side stub based on the MEP and it is
>required client behavior that will invoke the *right method* of the Call.
>Point that I want to note is that it requires something before the Call
>class to make the right Messaging choice.
>
>Personally I believe the concept of p2p messaging goes beyond the
>capabilities of the current implementation of Call and I don't think it will
>be elegant for us to squeeze the concept of p2p messaging *as it is* and map
>the messageprovider and messageconsumer to axis sever and axis client
>respectively. Instead may be a different approach such as where
>messagerprovider and consumer are axis servers with running services for
>both message sending and reception (inplace of the Call) for the p2p
>messaging; While supporting the current Call impl which has a very high
>usability.
>
>Comments ???
>
>
>
i personally would like to use util.concurrent.Future
(java.util.concurrent.Future in JDK5 backported to JDK 1.4
http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) in API
to denote delayed result such as async response message in MEP
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html
that is used for example in JBoss (though i think that API is overly
complex mix of homegrown async and EJB):
http://docs.jboss.org/ejb3/tutorial/asynch/asynch.html
it is still better than dealing with callbacks IMHO:
http://www.onjava.com/pub/a/onjava/2005/02/23/remoting.html
and then there are some other interesting ideas mostly around metadata
annotations like this one:
http://jroller.com/page/talipozturk/20050117#asynchronous_methods_in_java
thanks,
alek
>Regards
>Chathura
>
>
>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] async/messaging API?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Shawn Dahlen wrote:
>>i personally would like to use util.concurrent.Future
>>(java.util.concurrent.Future in JDK5 backported to JDK 1.4
>>http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) in API
>>to denote delayed result such as async response message in MEP
>>http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html
>>that is used for example in JBoss (though i think that API is overly
>>complex mix of homegrown async and EJB):
>>http://docs.jboss.org/ejb3/tutorial/asynch/asynch.html
>>
>>
>
>I looked into the use of Future recently in JDK5, but I didn't know that
>it was backported. I think it would be wise to at least look into for the
>async capabilities.
>
>
>
>>it is still better than dealing with callbacks IMHO:
>>http://www.onjava.com/pub/a/onjava/2005/02/23/remoting.html
>>
>>and then there are some other interesting ideas mostly around metadata
>>annotations like this one:
>>http://jroller.com/page/talipozturk/20050117#asynchronous_methods_in_java
>>
>>
>
>Has anyone done research into the potential projects that may offer
>code annotations
>in JDK 1.4? I think this will have some importance as we attempt to
>simplify the
>programming model. I know of Apache Attributes.
>
>
here is a complete backport of JDK5 annotations that is binary
compatible with JDK 1.3/1.4
http://backport175.codehaus.org/Overview
alek
--
The best way to predict the future is to invent it - Alan Kay
[Axis2] async/messaging API?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
resent with fixed subject.
Chathura Herath wrote:
>>>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?
>>>
>>>
>
>To my understanding MEP doesn't say anything about whether the service is
>sync/async and if I'm right that is a user decision which says how the
>client will behave after sending the out message and till the reception of
>the in message. Similar argument is valid for the server side. This get
>fussier due to the usage of the Transport being oneway/twoway(e.g. Http is a
>two way transport and would require a response in the transport level
>despite the service call being sync/async).
>So three things to note are
>1) MEP
>2) sync/async behavior of the service
>3) behavior of the transport.
>
>Axis2 was architected with Asynchronous in mind, but Synchronous ws calls
>were of great significance. So the receiver concept is expected to
>differentiate the behavior of the message path inside the engine which will
>be determined based on the MEP in the WSDL and service being a sync/async.
>Further the transport layer complexity will be handled inside the
>TransportReceiver s and TransportSender s.
>
>
>
>>>Wouldn't the Call (or
>>>MessageClient) class drive the exchange pattern?
>>>
>>>
>
>Not right now in Axis2. If you look at the Call class you ll see that it
>provides a generic API so that client Stub can use Call and invoke the
>*right method* to get the expected behavior (Sync/Async and MEP). Basically
>we will eventually codegen a client side stub based on the MEP and it is
>required client behavior that will invoke the *right method* of the Call.
>Point that I want to note is that it requires something before the Call
>class to make the right Messaging choice.
>
>Personally I believe the concept of p2p messaging goes beyond the
>capabilities of the current implementation of Call and I don't think it will
>be elegant for us to squeeze the concept of p2p messaging *as it is* and map
>the messageprovider and messageconsumer to axis sever and axis client
>respectively. Instead may be a different approach such as where
>messagerprovider and consumer are axis servers with running services for
>both message sending and reception (inplace of the Call) for the p2p
>messaging; While supporting the current Call impl which has a very high
>usability.
>
>Comments ???
>
>
>
i personally would like to use util.concurrent.Future
(java.util.concurrent.Future in JDK5 backported to JDK 1.4
http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) in API
to denote delayed result such as async response message in MEP
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html
that is used for example in JBoss (though i think that API is overly
complex mix of homegrown async and EJB):
http://docs.jboss.org/ejb3/tutorial/asynch/asynch.html
it is still better than dealing with callbacks IMHO:
http://www.onjava.com/pub/a/onjava/2005/02/23/remoting.html
and then there are some other interesting ideas mostly around metadata
annotations like this one:
http://jroller.com/page/talipozturk/20050117#asynchronous_methods_in_java
thanks,
alek
>Regards
>Chathura
>
>
>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
RE: [Axis2] Fw: [Axis 2] Messaging and Service Models
Posted by Chathura Herath <ch...@opensource.lk>.
Hi all,
Few things I want to note.
> > 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?
To my understanding MEP doesn't say anything about whether the service is
sync/async and if I'm right that is a user decision which says how the
client will behave after sending the out message and till the reception of
the in message. Similar argument is valid for the server side. This get
fussier due to the usage of the Transport being oneway/twoway(e.g. Http is a
two way transport and would require a response in the transport level
despite the service call being sync/async).
So three things to note are
1) MEP
2) sync/async behavior of the service
3) behavior of the transport.
Axis2 was architected with Asynchronous in mind, but Synchronous ws calls
were of great significance. So the receiver concept is expected to
differentiate the behavior of the message path inside the engine which will
be determined based on the MEP in the WSDL and service being a sync/async.
Further the transport layer complexity will be handled inside the
TransportReceiver s and TransportSender s.
> >Wouldn't the Call (or
> > MessageClient) class drive the exchange pattern?
Not right now in Axis2. If you look at the Call class you ll see that it
provides a generic API so that client Stub can use Call and invoke the
*right method* to get the expected behavior (Sync/Async and MEP). Basically
we will eventually codegen a client side stub based on the MEP and it is
required client behavior that will invoke the *right method* of the Call.
Point that I want to note is that it requires something before the Call
class to make the right Messaging choice.
Personally I believe the concept of p2p messaging goes beyond the
capabilities of the current implementation of Call and I don't think it will
be elegant for us to squeeze the concept of p2p messaging *as it is* and map
the messageprovider and messageconsumer to axis sever and axis client
respectively. Instead may be a different approach such as where
messagerprovider and consumer are axis servers with running services for
both message sending and reception (inplace of the Call) for the p2p
messaging; While supporting the current Call impl which has a very high
usability.
Comments ???
Regards
Chathura
Re: [Axis2] Fw: [Axis 2] Messaging and Service Models
Posted by Srinath Perera <he...@gmail.com>.
Just one comments to add, I believe in the implementing all messaging
patterns on top of *One way*, but NOT believe in the implementing SYNC
on top of ASYNC nor ASYNC on top of SYNC. As well all have fed up with
seeing the sync all around us and values Async there is a danger we
might overdo by putting async in to everywhere.
> 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:
Yap I share the same view to handle the transports of the Endpoints,
1) User will state the transport of the Endpoint by URL it is bound to
or other means
2) Theoritically The framework will find the registered transports and
bring up the transport if it is not initiated/started. Even though we
said that the transport that are required by Endpoint is started that
always bound by the limitations of the transport. e.g. If axis is in a
servlet Container that will limits the "ports/URL patterns/when to
start" of the the End Point bound to.
3) then rest of the invocation is transparent and taken care by the Axis2
> 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.
I make the statement that the ServiceEndpoint is similar to the
Receivers based on the following segment from the initial mail
"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 same way the ServiceEndpoints do the Receivers decide how to
invoke the "business logic" and sends a response if required! Receiver
(e.g. InOutSyncReciver) is placed in the end of the input pipe and the
correct receiver is picked up based on the correct MEP and Sync/Async
behaviour
I was bit confused with the ServiceEndpoint and the MessageEndpoints
...and as I understand now ServiceEnpoint are what resembles the
Receivers .. supports the
conventional Web Services as Axis2-M1 have. On the other hand the
MessageEndpoints are something (relatively )new and not yet supported
in Axis2-M1. +1 to take them in!
Thanks
Srinath