There are those who perceive the notion of and concepts within Service-Oriented Architecture (SOA) as being something new and revolutionary. That couldn’t be farther from reality than hot is from cold.      The concepts of SOA have been in existing and practice for decades. The main difference is that with the "invention" of SOA the driving forces are oriented around open standards. Previous approaches were platform, methodology, or protocol proprietary. These ancestors (CORBA, J2EE, COM/DCOM, DCE, etc.) did not benefit from industry wide accepted standards. They did have the notions of request/response, modularity, message passing, and interfaces.      Another major advancement, in addition to open standards, is the association of SOA and business processes. By associating SOA with business processes allows one to view their business/enterprise from a process perspective. An SOA provides a means of aligning IT (strategy, investments, and architecture) with the Business (strategy, investments, and architecture).      A myth of the SOA phenomenon is the Web Services = SOA and SOA = Web Services. While Web Services made be the most logical implementation of an SOA, by no means are they the only implementation methodology. The real concern is trying to construct an SOA without the business in mind. There really is no way to divorce SOA from business processes.

The typical notion of a service in an SOA ecosystem is always a software component is a limiting concept. I propose to add the notion of "hardware services" to this realm. Typical services perform some unit of work that may be a stand-alone unit or it may be a sub-unit in a much larger business process. The notion of "hardware services" is fundamentally no different. Hardware devices provide a service that is consumed by a customer, just as a software oriented service. All services have an interface to which a service consumer must bind to in order to invoke the service. In the case of hardware services this is a software agent. The software agent provides the necessary service contract in order to invoke the hardware service. The software agent does not perform in other functionality except to expose the available operations of the hardware service. By adding the notion of "hardware services" to the SOA ecosystem expands the possibilities of where such an architecture could be applied.

Situation Those who are familiar with the OnStar system found in General Motors(GM) vehicles will understand this notion of hardware services easier. GM vehicles are equipped with a device that uses sensors in the vehicle to monitor and report the "health" of the vehicle. These hardware services have a software agent that provide the data to the OnStar satellite. In effect, these software agent could expose to a service consumer the diagnostic operations for the physical devices that make up the vehicle. Say that I have a fleet of GM vehicles as part of my rental car business. I may want to monitor the status of all of these vehicles, or maybe I’ve been having complaints about a particular one, in real time. I could invoke the software agent on the vehicle(s) and ask it to run the diagnostics on whatever hardware device I chose to monitor. Note: This is a hypothetical situation as such I make no claims that the above describe situation is currently possible with the OnStar system or that it is scheduled for a future release of the system.

I just returned from an SOA Conference in London where we entrenched ourselves in a discussion into the concept of an ESB (Enterprise Service Bus). You will not find an industry standard definition for an ESB, due to the fact that the industry can not agree upon the minimum list of requirements that can be stated as an ESB. It was the opinion of one participant that an ESB is a product, a thing. However, there were several other people, I being one of them, that stated that the concept of an ESB is definitely not a new concept. At its very core the ESB function as the transport mechanism for XML based messages using primarily SOAP based messages. We have been transporting messages for decades with various technologies, MQ the one that most commonly comes in to the mind of the wizards. A very pertinent question was posed by a leading SOA expert, Duane Nickull. Be sure to monitor Duane’s blog at Technoracle for this question. An ESB is not simply a COTS product that one can buy from a vendor, no matter what the vendor sales folks what to preach. An ESB is an architectural approach instead. A leading industry analyst from redmonk, James Governor, views an ESB as an architectural pattern. I tend to like that analogy for the simple fact that with an ESB you only purchase and implement the necessary functionality to handle, transport, XML messages in a reliable, secure, standards based fashion.