What Is Soa

SOA, or ServiceOrientedArchitecture, is an architectural approach to developing information systems. It involves creating a number of services, where each service provides access to, or exposes, one or more resources via some predetermined, agreed mechanism. Services are often, but not always, distributed on a network.

A service could expose a resource which is (for example) a database table or view, a set of related database tables or views, the functionality of a legacy application, one or more data files in any format, or data obtained from another service. This architecture only allows resources to be read or manipulated by client applications, or other services, via a set of predefined standards so that the underlying nature (i.e., the physical representation) of the resources are abstracted by the service interface, and therefore appear, interface-wise, to be equivalent to any other resource.

This approach stands in stark contrast to the use of (for example) centralized network-accessible database, application, or Web servers, as there is no single, centralized server from a client's point of view. Instead, there are multiple servers which may be distributed within the enterprise and may be accessible outside the enterprise. This does not preclude the use of a centralized database or application servers as underlying resources, but in the context of ServiceOrientedArchitecture, the data managed by the database or application server is accessible only via WebServices or similar approaches. Clients connect to services, and do not directly connect to database management systems or application servers.

While WebServices are a popular approach to building a ServiceOrientedArchitecture, it does not have to be based on WebServices. A ServiceOrientedArchitecture is any collection of multiple, interacting software servers, each focused on a specific task and working in the ClientServer idiom, instead of relatively few, general purpose, centralized servers. WebServices are one approach, but not the only approach.

ServiceOrientedArchitecture tends to embody a "don't replace, embrace" systems philosophy. It tries to address the pragmatic need to develop new information systems by recognising, accepting and leveraging the diversity of existing resources and systems, rather than trying to replace them with (for example) a single, unified, database management system.

ServiceOrientedArchitecture is a way to implement DistributedComputing, and may have commonalities with developing multi-threaded applications and those based on InterprocessCommunication?.

I'm surprised that among all the three- and four-syllable words above I don't see any reference to XML.

Pretty much all the SOA support I've seen or discussed comes back to XML as "the protocol" or "the language" used to get it done.

Which always amuses me, until someone strides into the holy Land of Engineering and declares, in a properly stentorian voice, "Behold, for I bring unto you the Stone Tablets wherein it is commanded that thou shalt implement this protocol in XML, so that we may better <MissionStatement>."

At which point amusement turns to terror, and the braver cube farm residents brandish their soldering irons and sound the battle cry while the rest become pillars of salt.

So, is there some other SOA strategy of which I am unaware that does NOT invoke the dark arts of XML?

-- GarryHamilton

What about CommonObjectRequestBrokerArchitecture? XML is just one possible transport protocol, right? Right.

When I originally wrote the SOA definition above, as I reached what is currently written as "via some predetermined, agreed mechanism," my fingers, unbidden by me, typed "via XML" instead.

"Avast!" I cried, "Foul fingers of doom! How darest thee?"

And yet... The three letters shone with an aura of indubitable rightness. Surely all things SOA are indeed XML, are they not?

Then a mighty voice roared out from nowhere and yet everywhere. "Fool! Is XML necessary for an A to be SO? Thou shalt endure an analogy: Must every RelationalDatabase be based on SqlLanguage, even though virtually every implementation is based on SqlLanguage? Would a RelationalDatabase be any less a RelationalDatabase for not using SqlLanguage?"

"Indeed not," I meekly replied, "in fact the opposite might well be true."

The analogy had struck me to the core. I could find no reasonable reason to regard XML as the only possible way to implement the predetermined, agreed mechanism by which services communicate, even if current strategies deem it so.

And from that point forward, there was no XML in WhatIsSoa, for an A is no less SO for being without XML.

-- DaveVoorhis

However, any introductory class/book on RDBMS should describe SQL (and they all do), not just speak abstractly about the fact that any relational language could be used. Concrete examples are essential to understanding/learning, and it is highly pragmatic to know what people are actually doing in the real world. So if SOA is 100% XML today (I wouldn't know), then yes, it should in fact be noted so in an intro. Or, if it's 10%, mention what the 90% is. -- DougMerritt

I recall with considerable fondness a database text I ran across several years ago, the title of which I've unfortunately forgotten, that formally and rigorously defined and described relational databases without a single mention of SQL. A definition should be abstract, or at least vehemently distinguish essential characteristics from popular implementations, lest the implementations be perceived as part of the definition. As, for example, tends to be the case with SQL and relational databases, even though the former isn't even an example of the latter. That said, I agree that realistic examples would be useful, but as I'm tired of seeing XML overemphasized, I shall stick to my assertion that XML in terms of an SOA definition is adequately covered by the humorous exchange above and in the related WebServices page, and shall leave the provision of said examples to someone else. -- DaveVoorhis

JiniTechnology (http://www.jini.org) is one excellent SOA technology that does not mandate the use of XML.

"Service Oriented Architecture" (SOA) is a term that describes any distributed, enterprise scale software system having a design with four core characteristics:

Functionality is exposed as a set of services.
Services make themselves available by registering with a lookup mechanism.
Clients find services only via the lookup mechanism.
Clients bind to services dynamically.

A service is a cohesive set of business functionality aggregated into a single interface. That interface is implementated by one or more software artifacts, which may be local or remote. Implementing an SOA enables an enterprise to define the essential services it requires to meet its core business needs efficiently, and to adapt rapidly to changing business conditions.

The loose coupling inherent in SOAs results in resiliency (self-healing), scalability, deployment flexibility, and increased reuse. Loose coupling also makes it possible to incorporate existing components with minimal intrusiveness to working systems. SOAs can mix and match implementation technologies, using the options that are best for each service (e.g. synchronous vs. asynchronous communication, participation in distributed transactions, idempotency, etc.) without impacting the decisions made for other services.

The technical benefits of SOAs, in turn, provide real business benefits, including business agility, the ability to leverage existing software investments, and support for Business Process Management (BPM). These benefits come from the elimination of "silos" and the increased availability of business functionality previously locked in legacy systems.

Aside from the four bullet points, most of the above is standard marketing bumf. Whether or not an SOA approach actually results in self-healing, scalability, deployment flexibility, and increased reuse, business agility, and so forth -- or whether it does so but only at a significant cost in other areas -- remains (as of August 2008) largely to be seen. In a few years, we should know whether SOA is of enduring value or merely yet another buzzword blip in IT history.

For scalability, services should be stateless. For performance, the amount of data being passed around should be minimized. One solution to this is to build a ServiceOrientedArchitecture on a SpaceBasedArchitecture. In this approach, services use a distributed space to share state, but are themselves stateless.

Is a record of state really necessary? Can not the SOA cloud work on state information which is passed in through the service request just as HTTP requests do?

[Yes, it's possible, but not feasible when transferring the record of state consumes an undesirable percentage of available bandwidth.]

Okay, now we're getting somewhere. Are you suggesting that the "record of state" needs to be such a large entity that you don't want to bally it about over the wire? Why is the record so big? Can not the requests for service be broken up into a series of requests that progressively drill deeper into a data store? Isn't this exactly what happens when a user digs through pages of stuff on a web site and follows the links that eventually get him to the content he wants? Am I missing something vital?

[Depending on the application, the state record could be significantly large or very small. In your example of navigating Web pages, the state record is little more than a pointer -- something that says "you are here" in a mainly static landscape of interrelated data elements. However, imagine a massively-multiplayer game where every client manages an army of individual characters each possessing a multitude of attributes, or a distributed economic simulator based on a discrete model with hundreds or even millions of individual nodes managed by each client. In neither case would a simple state record suffice. This is not just because transmitting the whole record would consume considerable bandwidth. It's also because such systems typically require simultaneous read & write access to all active clients' states in order to correctly move the game/simulation from one time quantum or "tick" to another. This doesn't necessarily mean all state must be centralised -- it can even be maintained by each client -- but it does mean only passing state information through the service request is insufficient.]

I would have answered "not generally" to the original question in terms of expressiveness (though I do agree with the points on feasible performance). Placing 'state in the service request', as with HTTP cookies, doesn't allow persistent interactions between more than two participants. For example, you cannot describe a forum or a wiki by passing state via service request. In the general case, SOA requires state. That said, individual services may generally be stateless: much state can exist in the 'construction' and 'GarbageCollection' of services (constructors + GC = mutable state in-the-large), and (as suggested) at the 'clients'.

Hmm. Is it possible that we are exploring applications that are not good candidates for SOA, then? The online game, for instance, doesn't seem like a distributed processing type of deal. Although I can imagine a game in which each client reports position change and other actions and gets result info for each time atom. So, a request might include a report of movement, weapons fire, etc., and a result might include collision results, weapons impacts, yada yada.

You misunderstand. ServiceOrientedArchitecture isn't about effectively leveraging the vast supply of untapped distributed compute resources. The individual services in an SOA architecture are very often centralized and isolated to a particular owner or machine, which simplifies management and security concerns. SOA is effectively about 'service mashups': taking diverse services from diverse organizations/branches, and combining them at the client. That last bit is important; it avoids a single point of failure, it avoids the hassle of creating intermediate services, it allows a wider variety of configurations, and it allows clients to have 'fallbacks' (i.e. via a lookup mechanism) in case the primary isn't available. But SOA is a just a baby-step in a promising direction.

In the case of the forum it seems like the same thing. Perhaps a forum just can't be well described in a SOA environment, but perhaps a SOA forum could service requests with a huge result containing everything affected by the change implied in the service request.

A forum can be described quite well in an SOA environment. It just can't be done without state beyond that carried by a 'service request'. That you even discuss what is "affected by the change" implies you are imagining a 'state record' outside the request.

I am blowing some serious smoke here because I've never tried to create such a massive online application built entirely around stateless servers. I'm merely asking newbie questions to see if the hype surrounding SOA is really All That or if it is Yet Another flash-in-the-pan technology that will be passe in a couple years.

The comment heading this section started by suggesting "stateless servers with SpaceBasedArchitecture". Thus, the point was about organizing state as opposed to being rid of it. SOA has never been stateless. As to whether SOA will be 'passe in a couple years': if so, it will unlikely be due to regression. Integration between businesses is only going to increase over time, and automating the more painful elements is a big deal. But the ServiceOrientedArchitecture (the architecture, not merely the tech stack) has a number of flaws that still constitute 'painful elements', such as authentication issues that arise from using a common 'lookup mechanism'. If SOA becomes 'passe', I suspect it will be because some newer architecture and technology stack has improved upon SOA in ways relevant to developers.

Okay, I'm beginning to see some light here. It seems that any non-trivial implementation of SOA is going to require a state record for the reasons listed above. Well and good. Now, how does a service finder point the client to alternative service providers that are all acting off of the same state information? Is this one of those "painful elements" that needs to be worked out? Or is there an existing mechanism for synchronizing all of the alternative service providers in a particular space?

SOA doesn't help you with that problem, but the approach you imply with your question is especially painful. Consider, instead, giving the service a reference to the state it is intended to manipulate.

Or is that the basic issue that we're trying to deal with here? I'm a little turned around on the question of state containment, ownership, and access/permissions. In particular I don't understand how stateless servers (in the original statement) can act without access to a well-known state repository, but where is that repository, and how does the aggregator know to point servers and/or clients to it?

I suspect the statement heading this section was made with a particular implementation of SOA in mind, such as Java-based SOA like Jini. Use of a SpaceBasedArchitecture actually allows you to do better than locating new services that use the old data: they let you use the old service, which can be replicated cheaply (stateless allows replication without synchronization).

External links:

http://en.wikipedia.org/wiki/Service-oriented_architecture