I thought that this was an interesting discussion that if was to be continued in my comments, many of you might miss it (I know how difficult it is to follow comments on blogs).
Mark believes that I didn’t answer his question. Hmmm… Perhaps I didn’t understand the question then.
I think that Internet mail is an application and I am sure that Mark agrees. And of course, lots of clever people designed the architecture on which that application is based. And I am sure that these architects had a set of architectural principles in mind during the design phase. Such architectural principles may match, be a superset, or a subset of the MEST ones. Exactly the same could be said for any asynchronous messaging-based application out there. That doesn’t mean that MEST is only about asynchronous messaging however. MEST is an architectural style in the same way REST is one and we can find many applications out there (not just the Web) that follow the REST approach. MEST is a set of principles (one-way messaging, services, constrains on the messages, no interfaces, implicit uniform message processing semantics at the service end point, focus on interaction contracts and other metadata, etc.) most of which, if not all, have probably already been applied in existing applications.
If the suggestion is that the principles on which the Internet mail application is based are those that MEST talks about, then I don’t have a problem with that. We never tried to suggest that MEST represents something new in distributed computing. MEST just gives a name to the set of principles we think are important when building service-oriented applications. Let’s not forget that the Web also pre-existed REST.
As for Stefan‘s question about the distinction between transport, transfer, and application protocols that I mentioned in my previous post… I personally see a transport protocol as the mechanism put in place for a message to be moved from one point to the next (just the bits). A transfer protocol is the set of rules (e.g. structure, extensibility, and composability) and semantics for processing that message after it leaves the originating endpoint and before it reaches the receiving one (please note that endpoints are logical here and represent the boundary between a service’s logic and the outside world). An application protocol represents the collection of messages (an interaction, a process) and associated semantics which are put in place to implement some specific functionality.
The way a particular protocol is treated is relative. For example, SOAP is a transfer protocol which treats both HTTP and TCP/IP as transport ones when building Web Services applications. However, HTTP is an application and a transfer protocol at the same time when building Web applications, with TCP/IP being a transport protocol. Most probably not everyone agrees with this distinction so I’d be very interested in other people’s views. Start blogging everyone (please wait until I catch up with all my many unread blog posts first though 🙂
3 responses to “MEST and email no2”
Ok, that’s better. 😎 I wasn’t trying to suggest that MEST wasn’t new, I just wanted a description of it (where’s that paper?!) and figured that asking how it compared to email – AFAICT, probably its closest existing style – seemed like the simplest way to get there.
I’m not sure that some of the constraints you mention there are actually architectural constraints though. For example, I don’t think “focus on interaction contracts” is a constraint, because I can’t picture how it’s constraining how components, connectors, and data are related. But I guess I’ll have to await the paper for the detail.
Hey Mark,
I agree, the use of the term ‘focus’ was not the best. Sorry. However, we do have some ideas on how interaction contracts or other metadata can play a constraining role in the architecture. Perhaps we may have to use a different role. We’ll see.
Where’s the paper you ask? :-((( You are absolutely right. Jim and I seriously need to get our act together and write it rather than just discuss it over IM 🙂
Re protocols, SOAP can be used two ways; as a layer-6 protocol akin to BEEP, or as an application protocol extension (so the “application protocol” descriptor would fit, but it really should be qualified as an application protocol *extension*). If you dig deep into SOAP 1.1 and 1.2, especially 1.2, you’ll see that the design decisions made regarding the use of HTTP primarily favour the latter approach. That also means that SOAP 1.2 (and SOAP 1.1), by specification, does *not* treat HTTP as a transport protocol. Of course, pretty much everybody who uses SOAP uses HTTP as a transport protocol.
BTW, if you wanted an example of a protocol which was an application protocol, but wasn’t a transfer protocol, consider RTSP and telnet. Both are more of a “control” protocol, and gets their jobs done through the submission of fine grained messages meant to signal some action to the recipient, rather than communicate the state of any particular resource as a transfer protocol would do.