SOA Roots

, ,
1

I thought with all the hype around SOA these days (everything is suddenly an SOA tool and everyone is suddenly an SOA expert and every company is “implementing” SOA) that a review of the roots of SOA might be in order.

‘Service Oriented’ Architecture was first described by Roy Schulte some years back. You’d think probably just a few years back like 2001 or something–but no, it was over ten years ago in 1996. Clearly Uncle Roy was on to something. (Edit: I’m sure SOA may have come from something even earlier, but I can’t find any reference.)

Since then we’ve heard talk of “implementing” SOA, using powerful new SOA tools, how SOA is a ‘break-through’ in software development, how this new ‘technology’ will revolutionize the industry.

As with most things that have a life of its own, the notion of SOA has been abused, subsumed, consumed, morphed, tweaked, adopted, promoted, and hyped until it’s hardly recognizable. Some claim that SOA has technical requirements, such as a service registry, or messaging, or orchestration, etc. How can a design approach have technical requirements? Must an SOA-type solution have a messaging component? Is the use of an ESB required? Well, no not really.

The only thing an SOA-style solution really must have is, well, services. Everything else is nice to have. Sure, the everything elses can go a long way to making use and reuse of those services more effective, but they are not requisite.

[Edit]A service doesn’t need to be a web service. Heck, it doesn’t even need to use what we’d consider a classic communication protocol at all. I saw the wikipedia entry for SOA and it mentioned that even a file-based solution could be considered a service, and thus fit in the SOA style. A service needs a contract and a way to talk to it–e.g. “drop a file named this in a directory named that to invoke service X.” Would you consider this to be a service? If not, why not?

This Gartner article tries to distinguish between the useful and the hype regarding SOA. Read it through and then look at when it was written. It scared me how applicable it still seemed even though it long predates most of the current SOA hype.

Alternative POVs welcome and encouraged.

2

Rob,

I agree that SOA has many roots in historical distributed computing technologies and frameworks.

As we have discussed a number of times, I am also leary of vendor- and analyst-generated hype tsunamis that seem to sweep away rational thought and well-reasoned architectures. This wave will pass and there will be something new to replace it. Like Object Oriented and Client Server much of what’s good will remain and be incorporated into the next new thing. Pure play products and consultancies will be acquired or assimilated or will shift gears to pursue new opportunities.

That said, I will make a few observations related to what I hope will be part of the value that remains when the dust settles:

  • SOA does not require web services (SOAP over HTTP/S) and SOA implementations that don’t include web services can certainly be successful. However, well-accepted interoperability guidelines from WS-I and others mean that I have a pretty good chance of trading partners successfully consuming my business services if exposed as web services.
  • SOA implementations can also be successful without any form of message bus or message-oriented-middleware. Certainly external trading partners or newly acquired divisions of the corporation are not likely to consume my Services using messages sent over MSMQ, JMS or MQSeries (or WM Broker for that matter). However, messaging provides the event-driven features that make building course-grained services that combine functionality from multiple applications much, much easier.
  • Successful SOA nearly always requires successful integration. All of the best practices that result in successful enterprise-class integration will be necessary to pull off successful SOA. Exposing new composite business-level services implemented on top of a spaghetti diagram of low-quality integration will result in some short-lived success with almost certain long-term failure.
  • There are lots of generation zero “services” deployed that are truly horrible. I see lots of soap rpc/encoded methods accepting a single string parameter into which I must stuff an XML document adhering to some unknown or poorly defined XML schema. These baby step pseudo-services require lots of sneakernet to get up and running.
  • Many developers, business analysts and architects still think and talk in terms of technology, interfaces, applications and protocols. Very few rise up above the details to think in terms of what business services a company (or government agency) really provides to its customers and how those services are delivered today. This is hardly new, but successful SOA requires a better understanding of the core business than successful internal or external integration which can succeed with more narrow, application-focused understanding.
  • I heard a consultant from a large professional services firm assert recently that BPM is the key to SOA and that integration products are not very important. I don’t disagree that BPM can be another useful tool, but I disagree that either BPM or SOA can succeed without successful integration architecture. BPM requires integration to access the functionality locked inside packaged and custom applications. Integration companies that lose sight of this and allocate too much R&D focus to BPM over their core integration products are also doomed to lose market share. BPM has a place, but its just pretty pictures without integration.

More to come…

Mark