Not that straight forward. How would you handle addressing which is part of the soap processing model in a transport. In my view other QOS are out of the question if you want to do multiplexing. Chathura
On 11/5/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote: > Hi All, > 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 -- Chathura Herath http://www.bloglines.com/blog/chathurah
