I am most interested in the space between the large domain standards efforts, NBIMS, oBIX, GridWise, and OGC. When two areas of the brain try to interact, the action is all at the synapses. It is at the synapses that new ideas are formed, and that new actions are embarked upon.
The organizing principles of the synapses are what IT calls the architecture. We posit that we want each instance of these domains to hide their internal procedures, and offer up a surface. That surface should be defined not in terms of the underlying procedures, but as services. The architecture for linking these big domains together, then, is Service Oriented Architecture (SOA).
Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different owners. It is natural to think of one person’s needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent’s requirements being met by a computer agent belonging to a different owner. There is not necessarily a one-to-one correlation between needs and capabilities; the granularity of needs and capabilities vary, and any given need may require the combining of numerous capabilities while any single service may address more than one need.
SOA provides a framework for matching needs and capabilities and for combining capabilities to address those needs. The purpose of using a capability is to realize one or more real world effects. In SOA, an interaction is “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects). This effect may be the return of information or the change in the state of entities that are involved in the interaction.
Under SOA, people and organizations, and in my world, embedded systems offer capabilities and act as service providers. Those who make use of services are referred to as service consumers. The service description allows prospective consumers to decide if the service is suitable for their current needs and establishes whether a consumer satisfies any requirements of the service provider.
SOA is scalable because it makes the fewest possible assumptions about the network and also minimizes any trust assumptions that are often implicitly made in smaller scale systems. The Architect who uses SOA principles is better equipped to develop systems that are scalable, evolvable and manageable.
As Don Box once said, “SOAP was designed to let computers surf the web for data the way people surf the web for eye candy." With SOA, they are able to negotiate and interact as well.
Anyone interested on SOA would do well to read the OASIS Reference Model for Service Oriented Architecture
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm