Taking up the Turner Challenge or Once more into the breach!

Rich Turner doesn't believe SOA exists and challenges SOA advocates to draw him a picture:

 

 

I'm happy to take up this challenge for a number of reasons. First, I'm a corporate IT application architect. I have no products to sell, but solving real business problems is what my employer expects me to do every day. Second, I find SOA to be an excellent architecture for individual applications and inter-application integration. Third, I've become increasingly frustrated with my inability to communicate my requirements for building distributed systems to the Indigo team. Now, this inability is not from lack of trying on my part or the Indigo team's part. I've engaged various members of the team in a variety of forums. Every person I've interacted with has been smart, dedicated, and genuinely interested in what I have to say. And yet, every conversation has left me feeling as if I dealing with people from some alternate universe. We use the same language, but our frames of reference are completely different. Perhaps this will help bridge that gap.

 

 

Part of the problem in defining SOA is that there is no generally accepted definition for software architecture. Here's the working definition that I use:

 

A system's architecture is comprised of the relationship between the individual elements of the system, the patterns by which those elements exchange information, and the mechanisms used for that exchange.

 

One of the nice things about this definition is that it "scales" all the way from the assembly language instructions and electrical pulse flowing through wires up to cross-enterprise business processes. As an application architect, I'm most interested in the architecture of distributed systems where those individual elements are mapped to processes running on various systems in a network, but I also delve into architecture on smaller scales as well. My job as an architect is to map the functional and system requirements of an application on to a set of technologies. That mapping is constrained by numerous factors (existing systems, fiscal constraints, company standards, the capabilities of my team, etc.). My answer to Rich's challenge is that service orientation is a useful architectural style that helps me better meet the business requirements within the context of the constraints.

 

 

In SOA, the architect makes a conscious decision to model the individual elements of a system as services which communicate via a set of asynchronous message exchange patterns. What real business problems does that solve? If you take a look at how most businesses work, you'll find that they are organized into specialized subunits. Each subunit takes responsibility for a particular business function (or set of functions). As businesses become more complex, they take on increasingly stylized forms of communications. Rules are established to describe the allowable types of exchanges between these subunits. Many of these subunits are even common across widely varying businesses. Almost any business of a sufficient size will have an HR department, a Finance Department, a Sales organization, etc. I find it very easy to map the requirements of various business units (even if they belong to separate organizations) to a service oriented architectural model. For example, it's very easy to explain to the non-technical business user that the Inventory service accepts an Inventory Request Message and returns an Inventory Level Message. It's easy to think of interacting with a service by imagining walking up to a person sitting behind a window, handing them a filled form, getting a slip of paper with a number (a correlation identifier), and then waiting for your number to be called to pick up the response. From there you can discuss how things are different if you want to be able to drop off the form and know that it will be processed or stand there at the window, waiting for a response or if you need to sit down for an interview to fill out the form.

Conversely, from the technology side, services and messages map quite well to a variety of constructs up and down the abstraction level stack. Typically, a service will map to a computer process, messages to some sort of network payload. The particular abstractions I like to use include a reliable messaging and queuing infrastructure, a text-based format for messages, and a common formatting/datatyping mechanism. I work primarily on Microsoft's platform, but I do have to integrate with other platforms. Although I've rolled my own implementation of each of these at times in the past, I'm really looking to Microsoft to provide solid, high-performance, wire-format-interoperable implementations. As such, one would think I'd be happy with Indigo, but I'm not.

 

 

The fundamental problem with Indigo is reflected in this statement by Bruce Williams (a member of the Indigo Team):

 

 

Uh, no! The best way to model services is with, well, services: messages and operations. Because the Indigo team desperately wants to hide all this stuff from the developer, Indigo doesn't really support SOA. To make life (allegedly) easier for the developer, Indigo makes it impossible for the application architect who wants to build true services. Even though all the underlying constructs are there in the Indigo model, they are completely hidden by this enormous pile of OO attribute-driven goo. Indigo assumes that if you're interested in messages, you want to process XML, WSDL, and SOAP. If you want to put the "A" in SOA, you're forced to muck around among the angle brackets. Why, oh why can't I design a message in Indigo without being forced into angle brackets or square brackets? Why oh why am I forced to slurp another service's operations and messages directly into my object model (just like the current ASMX infrastructure)? Have you guys ever heard of loose coupling?

 

 

I really wish the Indigo would take a walk over to the BizTalk group and have a look at the Mapper. It's a little crude, but at least it acknowledges that there's an important visualization of XML Schema that can help in designing messages and that I might not want to pull some other service's view of the world directly into mine. The great thing about the Mapper is that it lets me build a nice, self-contained façade between services. This is absolutely essential when dealing with external services, legacy internal services with their own idiosyncratic view of things, or those really nasty beasts, the third-party systems (ERP, CRM, etc.). Just because they expose some WSDL doesn't mean I want my tools crufting up object models based on those things. I need to be able to insulate my service from that stuff. BizTalk does that really well. Unfortunately, not everybody (or every application) needs the rest of BizTalk's rich feature set and rather steep price. Don't get me wrong. BizTalk rocks and is well worth the investment, if you need even half its features.

 

 

Here's what I'd like to see from Indigo. Stop pushing the [DataContract] and [ServiceContract] stuff as the primary way of developing with Indigo. Let us have direct, non-bracket-intermediated access to the Indigo message. Let us control the mapping between the external message format and our internal processing model.