Srinath,
Interesting concept!. Couple of questions -
Does it have support from any specs? Because it might need dialogue id
headers in the envelope, just like sessionId cookie in servlet
request.
Are there any other SOAP stacks which are dialogue-aware or atleast
have cacheing/session concept on server-side?
Why can't the applications reuse the existing mechanisms at servlet /
http level (session, application) to maintain dialogues?
thanks
venkat
On Sat, 26 Mar 2005 21:32:58 +0600, Srinath Perera <[EMAIL PROTECTED]> wrote:
> Hi All;
>
> I have update the toy "proposal for Core of Axis2". Since the new
> changes add a new approch handling the conversation of message I
> thought of posting it to the DEv list for comments.
>
> The Proposal introduces new concepts called Dialogs to capture the
> concepts of a conversation. Each SOAPEndpoint (formally a Web Service)
> should associate itself with a dialog. What SOAPEndpoint does is to
> hand over the Message in to a Dialog. The Dialogs can be exsits in
> scopes, Global, Session and Service. The Dialog can be exists
> independent of the Services and the same dialog can be shared by more
> than one SOAPEndpoint. This follows the notation of more than one
> people talking in a conversation.
> Receipt of each Message will add one more message in to the dialog.
> The dialogs can be longs or short, in the sense a dialog can expect a
> one message in fact making it one-way or it do something like
> accepting 100 messages and sending 200 messages. Axis2 implementation
> will provide Dialogs for the each well defined message exchange
> pattern. But Dialogs may be taking the form of N in M out.
>
> Dialogs are extending to Endpoint Dialogs to register with the
> SOAPEndpoint, which are initiated by receiving a SOAPMessage. But the
> dialogs that initiate with sending a SOAP message may take the any
> form as the user is one who executes them. Axis2 will provide inbuilt
> dialogs of both natures.
>
> To capture the concepts in Axis1.x like providers, the Dialogs are
> extensible in the following way.
> <dialog name="abc" class="pqr">
> <xxx class="x1"/>
> <yyy class="x2"/>
> </dialog>
>
> Here the Dialog has a name and an implementation class. It may have
> zero or more child elements with any name and one attribute called
> class. The implementation class should have an attribute and getters
> and setters for each element name. Each class attribute should point
> to a Java class that is available in the classpath and have a default
> constructer.
> e.g
> public class pqr{
> private x1 xxx;
> private x2 yyy;
> }
>
> Using this method the InOutSyncDialog that uses a provider is shown as
> follows.
>
> <service name ="echo" dialog=" InOutSyncDialog"/>
>
> <dialog name=" InOutSyncDialog">
> <provider class="provider-class"/>
> </dialog>
>
> Thanks
> Srinath
>
