Comparison of SOA to past architectures

SOA vs hybrid Web service architecture

Here the use of Web Services with traditional architectures is found to be meaningful because of the flexibility in having established programming languages and make compatible with older application designs.Adapters are often available if there is no support available for the custom development of Web Services.

Web Services as component wrappers :

The primary role of Web Services here is to introduce an integration layer that consists of wrapper services which enables synchronous communication via SOAP-compliant integration channels.The communication with other applications or outside partners and also to take advantage of the features offered by third-party utility web services leading to the main purpose of having integration layer.

Web Services within SOA :

SOA provides strong support for a variety of messaging models and in this context the support of service orientation principles (loose coupling) for specific design requirements will be made available.By making standardization on SOA across an enterprise a natural interoperability emerges that makes compatible for proprietary application platforms.

Common Principles Of Service Oriented Architecture

1.Services are reusable that is for  example say account service.So the operations in account service like GetAccount,UpdateAccount,AddAccount makes you to reuse each operation by multiple service requestors.

2.Services share a formal contract say you are opening a new account in a bank for that you need to fill the application form.So the completed application form is much like a contract between the service provider and requestor of the service.

3.Services are loosely coupled that is a condition wherein a service acquires knowledge of another service but still remaining independent of that service.

4.Services abstract underlying logic that is some functionality provided to the requestor service is hidden.

5.Services are composable that is reconcile the sub-operations into a single operation which is simply another form of reuse.

6.Services are autonomous that is self-governance and eliminating dependencies on other services.

7.Services are stateless.

8.Services are discoverable that is for example a service registry provides a discovery mechanism very much like a phone book allowing potential requestors to query and check for service providers.

Principles of SOA

Following are the principles of SOA:-

   1. Re-usability of services : Services are designed in such a way that they can be reused in the future.

   2. Stateless services : Services are designed so that their previous state  information is not stored. This feature supports the loosely coupled nature.

   3. Services share a formal contract : For services to interact they need to describe each services and the information to be exchanged.

   4. Composable services : Logic is represented at different levels, this feature facilitates reusable.

   5. Loose coupling : Services are not dependent on each other for operation.

   6. Services are autonomous : Services are not dependent on each other within the explicit boundary.

   7. Loosely coupled services : Services are designed in such a way that they interact with each other without the tight coupling and dependencies.

   8. Services abstract underlying logic : Service exposed via service contract is visible to outside world. Underlying logic other than what is specified in the contract is invisible.

SOA vs Client-Server architecture

Client-server has multiple intelligent clients which are connected to database on the server. In this environment the application logic will be placed in client software. Client work station is responsible for bulk of the processing, thus consuming most of the system resources and memory. Proprietary database connections were expensive and imposing latency. 

In contrast processing in SOA has an explicit functional boundary and related resource requirements. Most of the intelligence has been placed in the messages. There is no fixed processing ratio for SOAs.

Like client-server applications SOA also uses the visual basic and relational databases. However SOA requires that XML data representation architecture along with SOAP messaging has to be established. 

In client-server architecture the security is centralized at the server level. Operating system-level security can also be incorporated. That is the data is protected through a single point of authentication, but in SOA the security becomes significantly complex.

The major drawback of client-server architecture is the large maintenance cost. Updating the application code on each client caused high maintenance overhead.

Comparision of SOA with Past Architectures

SOA Vs Client-Server architecture:-
   
Application Logic    
client-server places its majority of logic in client software which controls user experience and backend resources
whereas in SOA any software capable of exchanging SOAP messages are service requestors,it partitions logic into autonomus units to provide resuability across applications.

Application Processing
               Since logic resides in client side it must process bulk data,it must establish its own database connections which are expensive.client side executables are fully statefull and consumes a steady amount of PC memory whereas in SOA      processing is distributed and consists of explicit boundaries and resourse requirements to deploy services

Technology:-
  Client-Server uses technology like visual studio,C++ and database like mysql,sybase and RDBMS whereas SOA expands by adding web technologies like HTML,CSS,HTTP along with XML and SOAP messages.

Security:-
       Client-server is centralized at server level security.it can also control client executables and operating systems and data is protected via single point of authentication whereas in SOA security is provided by WS
security framework.

Principles Of SOA

The Principles of SOA are:

1.Reduced Cost :-
        SOA enables extensive reuse of existing funtionality  and infrastructure in multiple integrated projects.

2.Increased Flexibility :-
        SOA quickly adapt to applications inorder to meet changing business requirements and new         technologies  over time.

3.Integrates Incrementally :-
       This is the key benefit of SOA. It enables the users to provide knowledge based solutions which can be   integrated later in incremental fashion.

4.Loosely Coupled :-
           SOA proponents are loosely coupled. It depends on dimensionality like
Time:-when time is loosely coupled there is no need to be up and running at same time to communicate.
Location :-when location is loosely coupled participants can change location without having to re-program,reconfigure or restart communication among partners
Interface:- it provides a generic interface to communicate among partners.

5.Vendor Independent :-
           SOA does not depends upon particular vendor products whether it is commercial or free and open source.This implies interoperability and portability for applications.

6.Service Composability :-
service composability can be broken up in to two basic principles: service discoverability and service composition.Service discoverability is meant to help one avoid the accidental creation of services that are either redundant or implement logic that is redundant.





   






 

cooking.dtd

<!ELEMENT recipes (recipe+)>
 <!ELEMENT recipe (recipe_head, recipe_body, recipe_footer?, document_info)>
 <!ELEMENT recipe_head (recipe_name, recipe_author?, meal_type)>
 <!ELEMENT recipe_name (#PCDATA)>
 <!ELEMENT recipe_author (#PCDATA)>
 <!ELEMENT meal_type (#PCDATA)>
 <!ELEMENT recipe_body (ingredients, directions)>
 <!ELEMENT ingredients (ingredient+)>
 <!ELEMENT ingredient (#PCDATA)>
 <!ELEMENT directions (direction)+ >
 <!ELEMENT direction (#PCDATA)>
 <!ELEMENT recipe_footer (serving?, preparation_time?, cooking_time?)>
 <!ELEMENT serving (#PCDATA)>
 <!ELEMENT preparation_time (#PCDATA)>
 <!ELEMENT cooking_time (#PCDATA)>
 <!ELEMENT document_info (document_author, date_updated, source)>
 <!ELEMENT document_author (#PCDATA)>
 <!ELEMENT date_updated (#PCDATA)>
 <!ELEMENT source (#PCDATA)>