While digging thru my referral logs, I found a link to a SOA news page from the Government Online International Network (or GOL-IN for short). I have no idea what this site is about, but it’s an interesting news feed on SOA. For example, I found this interview with Bob Sutor, IBM’s director of WebSphere infrastructure software titled “SOA Is So Necessary“. GOL-IN gets their news via News Is Free, too bad then they don’t in turn provide their own  RSS feed.

I was re-reading the Microsoft Architecture Overview by Michael Platt that’s up on Architecture Center. It’s a little old, but still very valuable. In the overview, Michael discusses four perspectives on the enterprise architecture: business, application, information, and technology which are commonly collectively referred to as BAIT. (Note, I think it was Meta Group coined the term BAIT, but I’m not sure. Whoever did come up with the term, I’m pretty sure that it wasn’t MSFT). However, as we march forward building services, I wonder if we need to regularly consider a couple of more perspectives.

I don’t think service-orientation dramatically affect business or technology architecture. One of the big advantages of using web services to implement your services is that you can reuse a lot of the web-based technology infrastructure that companies spent the later part of the nineties building out. Likewise, while services will enable organizations to be agile and better achieve their business goals, I don’t think it changes the actual goals significantly. However, application and technology architecture change radically when moving from an application-centric to a service-oriented approach.

When considering services, the application perspective is broadened to include both applications and services. According to our conceptual architecture, an application implements a user interface while a service is a discrete unit of logic exposing a message-based interface. Even though they are both typically written in code, I’m not sure lumping them together is the right architectural approach. Building a single service has many architectural similarities to building an application, but an SO design also has to tackle the architecture as a system-of-systems which the application-centric approach never had to worry about.

Likewise, the information perspective currently covers data both inside services (or apps – here the distinction is less important) and inside messages. Obviously, the approach to data private to a service will differ greatly from the approach to data inside messages. Things like transactional integrity, immutability, extensibility and encapsulation apply very differently to data and message architecture.

Each of the perspectives covers many different subtopics, so maybe there’s no need to break services out from applications or messages out from information. However, I’m on record stating that I think using services “represents a fundamental change to the architecture model that the vast majority of systems running today were built on”. Thus, I think that fundamental change should be surfaced in language we use to describe the architecture, since language influences thought. Granted, BSMAIT isn’t as cool an acronym as BAIT, but it’s far more representative of the way the next generation of systems are going to be architected.

When you create a system with web services, are your web services components or are they standalone applications? While this might seem like a semantic question, it is actually a very big deal, with a lot of implications in terms of your overall application design, as well as the design of the web services themselves. [Rockford Lhotka]

What’s funny is that it IS a semantic question, and that’s what makes it such a big deal. 😄

Seriously, Rocky argues that web services should be thought of as applications, not components. I completely agree that a web service is “not a tier in an application” and that both services and applications have clearly defined boundaries. I also think he’s on the right track when he writes that many application design principles apply to services. For example, both applications and services have data and business logic layers. But I would call the top layer of a web service the messaging layer, which has only superficial similarities to the presentation layer of an application (i.e. that’s where input and output with the outside world is handled).

However, services also share similarities with components. Services, like components, don’t stand alone. They may not trust each other, but they need to work together to some extent in order to accomplish work. This leads to design questions for services that are similar to component design questions. How do I determine which pieces of required functionality go in which services? How much process code is included in the data management services? What’s the best way to design a service to optimize reuse?

In the end, services are fundamentally different animals than applications or components and I don’t think we as an industry have enough experience building systems with them yet.

I think it made the rounds in the blogsphere, but I’ll post it just the same: Pat Helland’s TechTalk on TheServerSide.NET was published late last week. You know it’s not your run-of-the mill interview when one of the questions is: “Why is Hooking Shit Together a more appropriate term?” and answers like ” Sometimes I want to talk about cleavage a lot”.

Seriously, one of the things I think was most important was Pat’s answer to the question on integration challenges:

When you’ve had a couple apps that have been independently designed, they have different assumptions about the world. Different assumptions about inventory, different assumptions about customers; they probably don’t even have the same snail mail address format. It’s true that we can connect the bytes back and forth with IP and TCP today, but that doesn’t do me anymore good than if I can pick up the telephone and talk to China, and if I’m speaking only English, and they’re speaking only Mandarin, we still can’t communicate very effectively. I can hear some cool sounds, but it doesn’t help get work done.

The same thing’s occurring when you bring applications together. The semantics of the interaction is a challenge. It’s very, very difficult across an enterprise to get a common understanding of what a customer is, is a great example. Because, this half has got these fields, and that half has got those fields, and maybe you can get some common fields of understanding, but there’s still all these differences that are in there.

A huge advantage that we have is XML. XML and XML Schema have allowed for at least the expression of what the data formats look like, even though that hasn’t helped with all the semantics. But it’s a good start. We don’t have to worry about parsing, we don’t have to worry about a lot of those details. But we still have a huge road ahead of us in terms of rationalizing how we understand the data across differently and independently designed applications.

This leads back to the SOA vs. SOP question. Being able to send a message is one challenge. It’s an entirely different challege to get a consistent idea of “customer” or “order” across your enterprise systems. Both challenges are important but distinct and are important to different levels of architect.

I also thought his best practice comments were facinating:

I would argue that the biggest best practice is pragmatism. Don’t do anything unless it makes financial sense.

Service-oriented architectures allow you to make whatever business choice fits. Because it talks about these being independent things, that can then hook together with others, using messaging, and using the sequences of messages that flow. That then takes the decisions of about what you bulldoze and you don’t bulldoze and puts it back where it should be: in the pragmatic business guy’s hands.

This leans heavy to towards Realist, but that doesn’t make it any less true.

Don pointed out to Goran that the Indigo definition of “a service is simply a program that one interacts with via message exchanges.” Goran pointed out that that definition “really doesn’t highlight how it’ll help a customer”. I think part of the reason they are both right is that they are talking about different things. I would say Don is talking about Service Oriented Programming where Goran is talking about Service Oriented Architecture. This gets back to the levels of architecture that I blogged about. Platform tools like Indigo are components used in systems. I’m guessing the customer’s Goran mentioned are at the system-of-system level for whom the messaging plumbing is below the abstraction level they care about. 

Of course, SO* buzzwords are thrown about with such frequency these days it’s hard to keep track of the difference.