SOA-Service-Oriented Architecture

In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In a SOA environment, nodes on a network make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (i.e. using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology.

Unlike traditional point-to-point architectures, SOAs comprise loosely coupled, highly interoperable application services. These services interoperate based on a formal definition independent of the underlying platform and programming language (e.g., WSDL). The interface definition encapsulates (hides) the vendor and language-specific implementation. A SOA is independent of development technology (such as Java and .NET). The software components become very reusable because the interface is defined in a standards-compliant manner. So, for example, a C# (C Sharp) service could be used by a Java application

SOAP:Simple Object Access Protocol (SOAP) is a protocol for exchanging XML-based messages over a computer network, normally using HTTP. SOAP forms the foundation layer of the web services stack, providing a basic messaging framework that more abstract layers can build on. SOAP can be used to facilitate a Service-Oriented architectural pattern.

Key Points:

• Service-oriented architecture is rooted in object-orientation but adds a layer of abstraction. I like to think that service-orientation is not a departure from object-orientation, but rather an evolution. Services orchestrate calls to discreet business objects to satisfy requests. Objects are enlisted, behind the scenes, to formulate a response.
• The openness of the technologies is exciting and easy to use. The current industry work on standards around UDDI, WSDL, Web Services, etc. promises that more and more applications can be constructed from constituent services rather than re-invented domain-specific code.
• The statelessness of the technologies can be a challenge for performance heavy applications. Be aware of the non-functional requirements of the solution you want to build. Sometime line-of-business applications desire long-running transactions that are better suited to other distributed application technologies.
• Design your solution for Web Services - you will have different approaches than you would for Remoting or DCOM. Again, remember that service-orientation is appropriate for some business applications, but not all. A service-oriented architecture is one possible architecture pattern to consider when designing solutions.