The First Day

The first day of the Applied XML Developers Conference has ended, and I am trying to digest the extreme amount of information that has been bulk-loaded into my brain via PowerPoint. I'm really impressed with my fellow attendees -- everyone here is very intelligent and passionate about technology.

Someone (I think it was Rory -- I'm in my room now and off the net, otherwise I'd grab the link) blogged about how the first day's content was more philosophical rather than technical, and therefore not conducive to blogging. I disagree -- I think the philosophical content that was presented today has been great blog fodder, since there's a lot of new things to form opinions about.

Don's Presentation

Don Box's presentation really crystallized a lot of concepts surrounding service-oriented architectures for me. I really like the idea of software-as-integrated-circuits analogy.

One of the core takeways from Don's presentation was that the power of SOA comes not so much from the services themselves, but from how those services are composed into larger systems. Service-oriented systems extend their functionality not by making the services themselves individually do more, but by composing those services into larger systems and create new messaging routes through those services. Thus, the interfaces presented by those services remain relatively static (and manageable) over time, but this fact does not mean that the functionality of systems based upon those services cannot grow.

I didn't really grok this concept until the IC analogy was brought in. Once that was there, it all made sense to me. Consider the humble NAND gate. This little piece of circuitry is very simple - it just takes two inputs and outputs the negated result of ANDing those inputs together. One might say that this circuit implements a "NAND" service that takes two boolean parameters as input. Although a single NAND gate doesn't do very much by itself, anyone who uses the NAND service knows exactly how that service will behave. This makes using the NAND gate very simple from a consumer perspective.

What's really cool about NAND is that you can use that service (and that service only) to evaluate any boolean logic expression. Pass the same value to both parameters of NAND and you get NOT. AND is just the result of negating NAND. Negate both inputs and AND them together and you've got OR. Since all three operations can be defined solely in terms of NAND (or operations themselves derived from NAND), the NAND gate can do fantastically complex things that its interface doesn't support natively -- it's just up to the consumer to wire up the appropriate circuit.

The NAND gate is a great example of how a system of small, well-defined services can perform operations of arbitrary complexity if the flow of messages through that system can be appropriately specified. Maintenance of the service internals is less of a problem because each service subscribes to an ideology of "do one thing, and do it well." Thus, the internal complexity of that service is minimized -- and reducing complexity is the easiest way to increase the long-term maintainability of a piece of software.

So, this mentality means that we build lots of small systems that don't do a whole lot by themselves. In general, they receive a message, perform some logic based upon the contents of that message (perhaps altering the contents of that message in the process), and send the message off to the next destination. WS-Routing allows us to encode the next destination within the message itself, so individual services don't have to know too much about their role in the larger whole. This promotes service independence and reduces the number of explicit interfaces that an individual service must support. It also means that we don't need an external mediator to manage the interaction between individual services -- the mediation information is encoded within the message itself. Thus, as long as the message can be guaranteed to survive its trip through the service pipeline (which WS-ReliableMessaging addresses), the originator of the message can be assured that message will have its intended effect.

I think the point of SOA is that is much easier to manage change in the composition of many small services whose interfaces are few and whose functions are well know than it is to manage change in abstractions that those services expose. Minimize the abstractions, maximize connectivity, and push the system's complexity into the connections between the services and not into the services themselves.