Web Services -thoughts on service orientated architectures |
Saturday, May 31, 2003 Reliable Messaging and Loosely Coupled I think this is a measured response to some popular misconceptions about enabling reliable messaging in a loosely coupled framework ( I use the word framework as I am not sure what else to use, I could use environment, space, etc). One of the key misconception is that this is a transport protocol issue - it is a mediation issue among application protocols. The applications can be anywhere in the seven layer stack and still enable reliability. In Reliable Messaging Doug Kaye gets it partially right in that the three alternatives presented in the article Sending an unmistakable message will probably not be the solution. I would have thought that Doug would have recognized this a problem that requires a loosely coupled solution. Or at least a minimalist approach, otherwise the degree of agreement required by every end of the reliable conversation becomes too complex just considering several point-to-point conversations. When the problem is extended to multi-party conversations the problem forces a loosely coupled approach. For this discussion I would like to define reliability a little more precisely into three categories
Messaging CategoriesThese definitions are intended for discussion, not as an absolute definition. The intention is to show the wide definitions of reliable messaging. These three categories are not absolutes but should be thought of as points in a spectrum. Into this mix could be thrown message ordering, and once and once only, at least once, and best effort semantics. However I think the point is made even with this limited categorization. To achieve any level of reliability, there are a few assumptions that must be made that are consistently overlooked about to the environment the solution is to be deployed in. The Environment
The final factor is that all these parameters are moving independently driven by widely different business requirements at different times and on a different time scale. Therefore to presume a homogeneous environment is a false assumption except in the rarest of cases. Traditional techniques have attempted to force homogeneity by deploying the same software at every node. This solution works when one partner has power over the others and/or deep pockets. This then puts the responsibility for change management and the definition of all interactions onto the partner with the "power". If the business world is considered to be more of a mesh or grid of relationships than a set of independent hub and spokes it becomes obvious that forcing homogeneity does not scale. The objective of standards in this area should be to create framework standards to enable loose coupling of systems rather than imposing a rigid standard that forces tight coupling on all participants. This is where there is a need for frameworks/platforms based on a Services Orientated Architecture (SOA) to enable reliable conversations among all parties and enabling change at everyone's own pace. The solution is a flexible mesh capable of supporting heterogeneous nodes and change. Framework standards such as WS-Coordination allow multiple parties to interact with the minimal amount of shared information - i.e., an unique coordination-id. This minimalist approach to protocol standards specification is much more aligned with a loosely coupled world than over specified standards such as ebMS. Over specification before there are substantial working implementations and real world experience rarely results in a broadly accepted standard. Focusing on solving real business problems through a loosely coupled SOA and a minimalist approach to standards will accelerate adoption faster than complex standards trying to solve complex technical problems in a complex problem space. We need to focus on the intent not on the technology.The intent should be to create the flexibly and adaptable mesh not hard wired connections Comments []posted by John McDowall | 7:54 PM |
|
||||||||||||