axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <hemap...@gmail.com>
Subject Re: [Axis2] Fw: [Axis 2] Messaging and Service Models
Date Fri, 04 Mar 2005 04:07:57 GMT
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

Mime
View raw message