Comparison of SOA with Past Architectures

SOA vs Client-Server Architecture
Application processing
The majority of the application logic is placed into the client component resulting a monolithic executable structure that controls the user experience and the back-end resources.
In case of Service-Oriented solutions, any piece of software capable of exchanging SOAP messages according to required service contracts can be classified as service requestor.
The application logic in SOA is distributed and the SOA principles dictate the partitioning of processing logic into autonomous units.

Application processing
Since the majority of the application logic is placed in the client component, the client workstation is responsible for the bulk of the processing.
Application processing in SOA is highly distributed.  Each service has an explicit functional boundary and related resource requirements.

Technology
The client-server applications paved the way for emergence of 4GL programming languages such as VisualBasic and PowerBuilder.
The technology set used by SOA actually has not changed as much as it has expanded.

Security
The client-server security is appreciated by many for is SIMPLICITY.
Security in C-S can be controlled within the client executable. Additionally, OS-level security can be incorporated to achieve a single sign-on.

In case of SOA, since the services are distributed providing security imposes significant complexities.  Multiple technology are involved comprising WS-Security Framework.

Administration
The maintenance costs associated with the distribution and maintenance of application logic across user workstation.

Maintenance challenges in SOA is easier and cheaper when compared to C-S architecture.


SOA vs Distributed Internet Architecture
Application Logic
The majority of the application logic is place into the server side components.
The distributed Internet Architecture emphasizes on the following principles-
--how application logic should be partitioned.
--where the partitioned units of processing logic should reside.
--how the units of processing logic should interact.

The differences between SOA and Distributed Internet Architecture lie in the principles used to determine the three primary design considerations.

The significant difference is in how services exchange information.  In distributed Internet architecture the components provide method that once invoked, send and receive parameter data.

Web Services communicate exchanging the SOAP messages.

Application Processing
Components are responsible for the majority of the application processing.
Distributed Internet Architecture promotes use of proprietary communication protocols like DCOM and CORBA for remote data exchange.

SOA relies on message-based communication.  This involves the serialization, transmission and deserialization of SOAP messages containing XML documents.  Processing also involves conversion of relation data into an XML-compliant structure, the validation of the XML document prior and subsequent to transmission, and the parsing of the document and extraction of the data by the recipient.

Technology
There is little difference in technology used for Distributed Internet Architecture and Service Oriented Architecture.

Distributed Internet Architecture consisted of components, server-side scripts and raw web technologies such as HTML and HTTP. 
The subsequent availability of web services allowed distributed internet architecture applications to cross proprietary platform boundaries.

Security
In order to ensure the safe transportation of information and the recognition of user credentials, while preserving the original security context, traditional distributed internet architectures incorporate security approaches such as delegation and impersonation.

SOAs heavily rely on the extensions and concepts established by the WS-Security framework.

Administration
Maintaining component-based applications involves keeping track of individual component instances, tracing local and remote communication problems, monitoring server resource demands and the standard database administration tasks.

SOAs typically require additional runtime administration involving exception handling with messaging frameworks. The other maintenance tasks include resource management.

Common Principles of Service-Orientation

The common set of principles mostly associated with service-orientation are listed below:

• Reusability 
• Formal Contract 
• Loose Coupling
• Abstracting the  underlying logic 
• Service Composability
• Autonomous Services
• Stateless Services
• Services must be discoverable

1. Reusability:
        Regardless of whether immediate reuse opportunities exist, services are designed to support the potential reusability feature.
        Service-orientation encourages reuse in all services, regardless if immediate requirements for the reuse exist. This reduces the development effort in future requirements.  Also this principle facilitates all forms of reuse, including inter-application interoperability, composition, and the creation of cross-cutting or utility services.

2. Formal Contract:
         In order for services to interact, they need not share anything but a collection of published metadata that describes each service and defines the terms the terms of information exchange.
         Service contracts provide a formal definition of:

• the service endpoint 
• each service operation
• every input and output message supported by each operation
• rules and characteristics of the service and its operations

3. Loose Coupling:
         Dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract.
         Loose coupling is a condition wherein a service acquires knowledge of another service while still remaining independent of that service.  Loose coupling is achieved through the use of service contracts that allow service to interact within predefined parameters

4. Abstracting the  underlying logic:
        The only part of a service that is visible to the outside world is what is exposed via the service contract.  Underlying logic, beyond what is expressed in the service contract metadata, is invisible to the outside world.
          This principle allows services to act as black boxes, hiding their details from the outside world.  The scope of logic represented by a service significantly influences the design of its operations and its position within a process. 

5. Composability:
          Services may compose others, allowing logic to be represented at different levels of granularity. This promotes reusability and the creation of service abstraction layers.
          This principle ensures that services are designed so that they can participate as effective members of other service compositions if ever required.

6. Autonomous Services:
          The logic governed by a service resides within an explicit boundary. The service has control within this boundary, and is not dependent on other services for it to execute its governance.
          This principle eliminates dependencies on other services.

7. Stateless Services:
          Services should be designed to maximize statelessness even if that means deferring state management elsewhere.
         Services should minimize the amount of state information they manage and the duration for which they hold it. 

8. Services must be discoverable:
           Services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic.
           Service discovery helps avoid the accidental creation of redundant services of services that implement redundant logic.

  Out of the 8 common principles autonomy, loose coupling, abstraction, and the need for a formal contract can be considered the core principles that form the baseline foundation for SOA.

Web Services and Web Applications

Lets first see what they actually mean.

Web services provide a standard means of interoperation between different software applications, running on a variety of platforms and/or frameworks. In a broader sense it means: " A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."

The purpose of a Web service is to provide some functionality on behalf of its owner -- person or organization, such as a business or an individual. 
Web services are sometimes called application services. Web services are not directly meant for the users but for the developers to aggregate/integrate the different services from different services providers to give users the flexibility to use various services on a single web application.
These services may be checking someone's credit, checking the inventory status or checking shipping status for a logistics firm.
AMAZON is the pioneer in web services frontier these days.

Now lets see what is a web application.
A web application is an application that is accessed over a network such as the internet or an intranet. 

A web application is a self-contained subtree of the web site. It uses Servlets, Filters, JSP, and the functionality provided by any other java code to provide a response to a client that makes an HTTP request.

Any application that uses a web browser as a client is actually a web application.
For example, a web site with a sign-in for the users or a web site with a message board 

Web Services

Web Services are actually the services that are deployed on the web. A Web service is a method of communication between two electronic devices on the network. Its a way of calling methods/functions in an application on the web from another application.

Web Services are an implementation of SOA.
In SOA there are mainly two actors, one is the service provider or producer and the other is the service requestor  or consumer. The consumer sends a request for the service and the producer serves the request with a response. The main characteristic of a web service architecture is that the service providers publish their service description which are placed in a service directory(think of this directory as the popular yellow pages). The consumers on the other hand perform a query against this directory to find what services are available and how to communicate with that provider.

Web services are the APIs on the web which allow applications to communicate with each other using XML, a meta data and using SOAP as protocol.

The heart of the web services are:

• WSDL(Web Services Description Language)
• SOAP(Simple Object Access Protocol) and
• UDDI(Universal Description, Discovery and Integration registry).

Let me briefly explain what they actually are.
WSDL is an industry accepted standard for defining an interface to a service i.e., the service descriptions are to be written in this standard language before they are placed in the service directory.
SOAP defines the protocol - on the network - for making requests and receiving responses.
Finally UDDI, is a standard for registering and searching web services within the service directories - yellow pages as it were - containing web services. Thus UDDI enables searching/discovery of various web services.

Web services are standardised by the W3C with the use of XML(eXtensible Markup Language) tags which form the basis for the web services. XML is actually designed to carry data and not display the data in a browser.

SOA???

Since this is my first blog on SOA, I would like to tell you all what SOA is all about?
One should note that SOA is not a technology and that SOA is an architectural approach to the software design that involves assembling systems from reusable components or services that may originate from different sources and underlying technical environments.

SOA  is an "IT architecture" based on reusable, well-defined services implemented by independent IT components.  These components are loosely coupled enabling the changes in the system much easier.
SOA  actually provides platform, technology and language independent services allowing greater flexibility in assembling new components or services to the existing system.

SOA marks the end of monolithic enterprise application and the beginning of more flexible and more adaptable business-centric applications.

SOA can be loosely described as an 'architectural solution' for making 2 software services communicate with each other.

Now let me tell you what is the need for SOA or how exactly SOA tries to overcome the deficiencies of the existing business processes?
Firstly SOA frees the services from the legacy environment and makes them available for easy reuse by people, processes and other applications.
This reuse yields speed and adaptability for faster execution of marketing campaigns, regulatory compliance and thus opening up new marketing scope to improve an organization's business performance.

SOA allows for the combining of existing functions with the newly developed functions, allowing for the creation of composite applications.
SOA actually leads to high-quality, low-cost applications that can be procured from third party suppliers replacing lower quality components thus lowering the risks in their projects.

Loose coupling of the functions/services helps preserve the future by allowing parts of the business and the technology that provides support to change at their own pace thus overcoming the risks involved in the monolithic approaches.