Here's my view on this. If I remember right there was some discussion way back on this and it ended up with the understanding that something like this ends up with a pub-sub architecture. So what I think is that this multiplexing could be handled as a different transport which abstracts all addressing and other QOS issues. The particular transport sender also handles subscriptions so Axis wouldn't know anything about it!
On 11/5/05, Chathura Herath <[EMAIL PROTECTED]> wrote:
Actually i am trying to implement this kind of transport multiplexing
thing for some other project and one further problem that i faced was
how to handle the addressing stuff. So IMO multiplexing should start
at the addressing out handler because the addressing headers are
different for the out going messages. This is kind of messy though and
kills the grace of the SOAP processing model. Further the nice
application for this, which would be WS-notification and WS-Eventing
both have ws addressing around.
Actually Eran think of a Notification framework where you have 20
Notification consumers. So instead of making 20 call invocations we
can write a transport (or an addressing handler) such that it will
deliver the same message to the different Notification consumers(20).
call.setToList(eprList);
call.invokeBlocking(...)
So the message will go through the soap processing model only once.
So only one OM for the most part. There are other complications like
different consumers requiring different policies, but from my personal
experience of Notification and eventing i know that almost all the
notifications that are sent out are same except for the addressing
headers.
Believe me this feature would come in handy when we eventually
implement Notification and eventing.
Chathura.
On 11/5/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> Hi Srinath,
>
> can't wedo this by changing the toEPR in the Call api and invoke the
> method ? Sorry if I understood this wrong.
>
> for example;
> call.setTo(eprOne)
> call.ivokeBlocking(.....);
>
> call.setTo(eprTwo)
> call.invokeBlocking(...)
>
>
>
> Srinath Perera wrote:
>
> >Hi All;
> >
> >Shall we add a support to users to send same message to more than one
> >recipients?
> >
> >Motivate for the doing this is if we need to send same message to 20
> >recipients, (e.g. Publish Subscribe) . If user create 20 Calls it will
> >be very expensive and if we do the thingy inside Axis2 we can set the
> >OM caching true and reuse at least part of the Message to multiple
> >invocations.
> >
> >I do not feel this should be done at the transport sender level (e.g.
> >We need different addressing properties). I feel we should have
> >different Pipe for each while sharing the same SOAP Body. I think
> >about something like MultiOutClient (or PublisherClient .. I am not
> >sure ) add to Client API
> >
> >I am thinking aloud :), this could actually get very complex
> >thoughts?
> >
> >Thanks
> >
> >Srinath
> >
> >
> >
> >
>
>
--
Chathura Herath
http://www.bloglines.com/blog/chathurah
--
Ajith Ranabahu
