Patterns Of Messaging And Web Services Focus Topic

KyleBrown has submitted the following Focus Topic proposal for PlopTwoThousandTwo. If you are interested in submitting a paper on this topic, or in finding a collaborator or reviewer for a paper on this topic, please post a message on this page:

Topic: Patterns of Messaging and Web Services

Abstract: Web Services are rapidly gaining acceptance as a key part of business-to-business communication and enterprise integration. While many web services implementations have been successfully deployed, there is as of yet a scant understanding as to what the best practices and common patterns are in this field. Closely related topics to this are patterns that relate to asynchronous messaging architectures; especially those that combine asynchronous message flows with composed XML messages. In this focus topic we will examine the first patterns in this emerging field and share experiences in this area.

Contact: Kyle Brown (brownkyl@us.ibm.com)

GregorHohpe and I have started work on taking some of the MessagingPatterns that were originally developed on Wiki and working them into a submission for PLoP. The MessagingPatterns page is a pretty good synopsis of the kind of work we've done -- hopefully we'll have a PDF file for people to download and review soon. --KyleBrown

Update -- we're currently shooting for three separate submissions:

KyleBrown and BobbyWoolf are going to submit a section of our pattern language on MessageBus and related patterns.

GregorHohpe is going to try to submit a section on Message content patterns.

RachelReinitz? is going to try to submit a section on Messaging infrastructure patterns.

I am helping to organize the focus group with Kyle. I have been working on Web Services Patterns and Messaging Patterns that I will submit this year. --AliArsanjani

OK, BobbyWoolf and I have finished the first revision of our paper, which we have submitted for Shepherding. If anyone is interested, you can see the paper at http://members.aol.com/ann1001001/MessagingPatterns516.pdf

KyleBrown

There is a strong sentiment from part of the WWW community that REST is a sufficient (messaging) architecture to support web services. Mention of REST concepts in the paper for the purpose of analyzing overlap, agreement and disagreement would seem appropriate if the "web services" part of the title here is meant in earnest. As for me, I'm not intimate with REST, but I'm quite well versed in the patterns discussed in your paper, so I'd be quite interested in a comparison. For instance, you deal with event notification as a special case. I don't know what REST says about that. -- WaldenMathews

As far as i know REST just talks about how to invoke operations. It doesn't talk about all the other stuff you need to build real scalable systems. --AnonymousDonor

OK, I've downloaded the REST Paper and I'm going to read through it tonight and see if I need to update our paper accordingly. However, remember that our paper is more focused on the "Messaging" part than the "Web Services" part of this topic... --KyleBrown

I read the paper, and it is a good summary. I think it misses some historical detail, particularly TCP/IP solves many of the same issues for the same reasons. This wheel is an old one, and I think it is worth including the equivalent structures.

So, for example, a message target can be its IP address. The IP sequence number is identical to the message fragment number. Many systems use the port to identify the particular channel on the TCP bus. Message timeouts and TCP timeouts are not distinct. And so on. Transaction id's (correlation id's) are associated with a particular connection in TCP so it is usual to leave them at a more logical level.

Moving up a level to http where REST lives. The address is encoded in the URL e.g. www.c2.com. The channel number is also encoded in the URL, appended to the address. The fragment number is unlikely to be an issue(http assumes that the transport will deal with it) , but if it is, then it may be included as a named identifier much as any other envelope specifiers can be included in the http header. The http protocols are somewhat richer in that they can easily nest information, as IP packets also nest their routing information. Perhaps you might include this capability too? Route recording becomes essential when dealing with secure messaging.

Other aspects of IP relate to pure infrastructural issues. A 'ping' message is useful to check if a peer is there or not. This would allow the messaging structure to be manage reliable paths. This may be a little deep into the architectural infrastructure for your discussion.

Another recent aspect of http handling is the use of application-level dynamic routing. A target address may not be known by the sender. Indeed the target may vary dynamically according to some information unavailable to the sender which may not be explicitly put into the header information. Such routers delve into the message itself to decide where a message should be sent according to various criteria.

Web-services leverage the existing http infrastructure with all this richness of behaviour, and efficiency. MOM tends to be more limited in that it assumes a permanently connected, proprietary infrastructure. Thus Fielding's argument that we don't need to reinvent the RPC semantics yet again. Sorry if any of this isn't relevant. Cheers --RichardHenderson.

I like your suggestion about looking back at TCP/IP. I have seen clients build routing mechanisms on top of EAI packages that mimicked TCP addressing. I have Message Management patterns included in my paper, so 'ping' could well be included there. I do have a pattern on content-based routing. There may be some similarities to the http handling you describe.

If anyone is interested, you can see my PLoP paper on integration patterns at: http://www.hohpe.com/Gregor/Work/docs/EnterpriseIntegrationPatterns.pdf

GregorHohpe

This focus topic and these papers lead to the book EnterpriseIntegrationPatterns. -- BobbyWoolf in Dec03

CategoryWebServices