Thanks Venkat for comments
> Does it have support from any specs? Because it might need dialogue id
> headers in the envelope, just like sessionId cookie in servlet
> request.
Yes (and No) :) , I get the Idea from the wsdl MEPs, there they define
an few MEPs and say there can be more. Basically I am in the mindset
that the stateless invocation of the messages (second message does not
know about the first message) will be replaced by the Messges M in N
out kind of stateful Web Services.
We are having trouble how to implement the Message M in N out type in
Axis2, I am trying to solve the problem.
The messaging framework is alreay there (e.g. Message ID ect .. I know
jaliya was working hard to implements similer senarios for RM )
> Are there any other SOAP stacks which are dialogue-aware or atleast
> have cacheing/session concept on server-side?
I get the Idea while reading about indigo Managers, it is like
rebirth, not a completly new being but not the old one as well ;)
> Why can't the applications reuse the existing mechanisms at >servlet / > http
> level (session, application) to maintain dialogues?
due to same reason you need ws-security when u have the https
Thanks
Srinath
> 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
> >
>
