Remembering the Future

The trick is to design services so that they can be actors in a wide variety of groupings (business processes).

This is tough. It requires a lot of experience and the ready availability of serious domain knowledge.

Good service boundaries do not "drop" out of decomposing discrete IT systems. They drop out of decomposing the "social network" that underlies a family of business processes. Decomposing the social network is mostly an empirical science:

• You need to put in probes and monitor traffic flows as they are, not as some ex-post facto Visio diagram claims they are and not as users (each of whom have their own complexity-reducing simplified mental models) tell you they are


• You need to hunt for simple repeating patterns in the apparent chaos of cross talk. I find it useful to do this anthropomorphically in terms of speech acts


• You need to find the feedback loops. They exist in any complex system and are the key to unlocking any underlying simplicities that are key to tractable implementation


• You need to find the key "nodes" in the power law distribution that governs (trust me) the connect-ness of the services network. In fact, I'd go so far as to say that if you do not get a power law distribution staring back at you from your analysis, repeat the analysis.


• Finally, you need to be lucky. The more detailed your emperical analysis is, the luckier you will be with your final services decomposition :-)

Topics: SOA | Architecture | Design

Last year I used Atom as the packaging format to ship system and business level events to a central monitor (I bet Coté would be up for a bit of that). I don't see why it would not be a good basis for enterprise concerns like messaging, authentication, or management interfaces. Atom, RSS and the Atom Publishing Protocol (APP) as a complement to REST could disrupt SOAP and WS.

The SOAP systems are going into their 3rd generation, but the same old skeletons of object mapping, synchronicity, design from code to wire and over-specification persist. For example, it would be curious to see how the Alpine Web Services proposal for Java might turn out if it targeted syndication XML instead of SOAP XML.

. . .

there are five reasons to that microprotocols - namespaced module extensions that inform and affect application behaviour - will appear as an alternative to WS and SOAP based technologies by targeting enterprise computing concerns like reliable messaging and tracking.

Topics: Atom | RSS | REST