Hi Eran -
On Mon, 28 Mar 2005 08:58:02 +0600, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > Hi Shawn and all, > > > > > Sorry - Resending with prefix. > > > > All - > > > > A few weeks back I posted a message on this list discussing the > > introduction of a low-level messaging model which in return would be > > used to create a higher-level service model. With the community > > preview release of Microsoft's Indigo platform, I would recommend all > > of those interested in the messaging concept to read through a series > > of blog entries hosted by TheServerSide.Net. > > > > http://www.theserverside.net/blogs/showblog.tss?id=IndigoP1 > > http://www.theserverside.net/blogs/showblog.tss?id=IndigoP2 > > http://www.theserverside.net/blogs/showblog.tss?id=IndigoP3 > > > > The programming model presented in those series of articles captures > > much of my intent in the original email. > > > > We discussed the value of WSA on the thread relating to an SMTP > > transport. I reiterate my position that WSA is fundamental to a WS > > Messaging platform (required for async messaging), and it appears that > > Microsoft has baked it directly into Indigo. We should make it > > extremely easy to explicitly set addressing information if need be. > > I also agree with you about addressing support for async messaging. But > IMHO, sync messaging should not depend on addressing. (I think I've > mentioned this in one of my earlier emails as well.) WSA provides a common way to describe the endpoint address and action to be taken. For a snyc transport, the sender could set the ReplyTo address to the WSA anonymous address (indicating that it would like the response delivered on the 'back' channel (the HTTP response). WSE 2.0 demonstrates this. I feel that WSA provides the defacto mechanism to describe routing information in a transport neutral manner, and should be used for all exchanges (thus minimizing debate on how this info should be placed in each new transport introduced). I think only legacy web services (SOAP+HTTP) should be able to get away without that info. I have been thinking quite a bit lately about REST and Web Services. I am a big proponent of document-based exchange, and currently feel that REST is a more appropriate solution for XML over HTTP (due to its simplicity), and that traditional Web Services don't offer much (especially when you consider how most individuals develop with code-first development in addition to the lack of tool support for contract-first development; and of course none of QoS specified in WS-*). What makes Web Services continue to blaze in my heart is the dream of an interoperable messaging system with qualites of service that REST cannot match. So REST for simple document-based exchange, and the future of Web Services (WS-*) for event-driven, transactional and reliable systems. WSA just seems so fundamental to that Web Services future (which I see as the Axis 2 implementation of course ;)). NOTE: I would definitely like to talk further about REST, especially since it has made me rethink fundamental issues with Web Services. Where do people in the conference stand here? > Anyway, the current Axis 2 has built in WSA support. The system is such > that, the engine *does not* depend on WSA. It works on set of parameters, > which are just like things found in WSA (see > MessageInformationHeadersCollection in the MessageContext). If addressing is > available a handler will fill the correct params, unknown to engine. > > > > > One thing I did like was their nomenclature. They removed references > > to client - server to really reiterate the fact that services act as > > peers through the exchange of messages with one another. > > I'm also +1 for having peer concept, rather than having client-server. > I think this peer concept shines through with Indigo's DuplexChannel where both peers implement a contract with all messages exchanged one-way (or so it appears with my first run through if Indigo :)). > When you look in to the third part of the tutorial u've mentioned above (the > purchase order example), for me it seems like Indigo has gone one step > further and it has tried to implement a business process engine. > It seems like Indigo has burnt in a BPEL like engine as well. > > I'm not saying that it's bad, but what I feel is current Axis is just a web > service engine and a BPEL engine is step ahead of that. I'm not sure If they are attempting to accomplish this with Indigo. Which part in particular in the PO example are you referring to? I will go back and take a look though. If I remember correctly, he was demonstrating a DuplexChannel. This type of channel is capable of both sending and receiving messages (it is a IInputChannel and a IOutputChannel). Peers would use DuplexChannels to communicate with one another (and I believe there is a IRequestReplyChannel for client-server topologies, although don't quote me on that one). All in all, I really find the Indigo concepts of a Port, Channel, Message, and Service to be extremely straightforward (and straight from the messsaging field). I would really like to understand how these four concepts play together before I pitch anything definitive. MS has spent a great deal of time in this area, and we should at least understand how they are approaching next-gen web services platform. > But I also like to see Axis having a BPEL engine, but will it be achievable > in Axis 2 ?? Perhaps in Axis 3 or 4. :) :) :) > > Regards, > Eran Chinthaka > > > > > Another interesting blog entry that dicusses Duplex vs. Request / > > Response MEP can be found here: > > > > http://hyperthink.net/blog/PermaLink,guid,97b52cfb-2863-4e8f-a604- > > 706eb07d63b8.aspx > > > > Definitely interested in all of your thoughts :) > > > > Shawn > >
