SOA VS DISTRIBUTED INTERNET ARCHITECTURE

distributed architecture consists of many components but it reduces problem of centralization on server.It provides a dedicated servers which shares and manages database connections.distributed architecture introduces a new physical tier web server,which replaced HTTP by RPC protocol to communicate between remote web and application server

Application Logic:
 SOA is similar to distributed architecture provider logic lies in server side but diffierence lies in principles.
components  are tight coupled and processing is wasted to locate component at runtime whereas web services  are loosely coupled thus it introduces oppurtunity for reuse and extensibility.

Application Processing:
 Distributed architecture promotes proprietary protocols like DCOM and CORBA for remote data exchange.It supports creation of stateful and stateless components.
  SOA relies on message based communication,it involves serialization and deserialization of SOAP messages
containing XML document payloads

Technology:
  Distributed computing consists of components,server side scripts and web technologies like HTML and HTTP.SOA consists of distributed objects using Xml and web services.

Security:
  Traditional security architectures includes approaches like delegation and impersonation,encryption to HTTP protocol.SOA rely heavily extension and concepts provided by WS-Security framework,SOA emphasize on security logic.SOAP messages provides header in security logic can be stored.

Administration:
 Distributed  architecture introduces web server and physical environment using HTTP.SOA requires additional runtime administration.problems with messaging  framework can go undetected than with RPC based data exchange.

SOA VS HYBRID WEB SERVICE ARCHITECTURE

Web services as component wrappers:
   The primary role of web service is to introduce integration layer consists of wrapper service that enable synchronous communication via SOAP messages and enable features offered by third party utility web services.SOA provides support for messaging model and specific  design requirements provided by SOA principles, loose coupling,point-to-point communication.

Web Services Within SOA:
   SOA can vary in size and quality.SOA are built with web services designed to automate one or more business process it promotes organization of services into specialized layers that abstract specific part of enterprise logic.it provides interoperability for proprietary application platform that evolves business automation process

SOA versus Distributed Architecture:

Application logic:

Distributed applications place all their application logic on the server side. Here the emphasis is given on,

1. how application logic is partitioned.
2. where the partitioned units of processing logic should reside.
3. how the units of processing logic should interact.

In distributed applications components are designed with different degrees of functionality and to what extent they are considered reusable by other tasks. Components residing on same server communicates API’s. In SOA web services establishes a loosely coupled environment, allowing individual services to participate.

Another difference is in how services exchange information.  Traditional components provides the methods which send and receive parameter data. Web services communicate with SOAP messages which rely on document-style messages.

Distributed internet architecture use proprietary communication protocols like DCOM and CORBA for data exchange where as SOA relies on message-based communication.

Security:

To ensure safe transportation of information and to identify user credentials encryption is assed to HTTP protocol. SOA emphasizes on placement of security logic onto messaging level. SOAP messages provide header blocks where security logic can be placed.

SOA vs Past Architecture

SOA vs Client Server

• Mainframes provided the first “client-server” computing with synchronous and asynchronous communication

• CICS – conversational and non-conversational mode

• 1980s – two-tier client server with fat clients, GUI, database. Dominated the 90s

Client Server Characteristics

• Bulk of the application logic resides with the client

• Monolithic executable on client

• Business rules were maintained in stored procedures and triggers on the database

• This abstracted a set of business logic from the client and simplified data access programming

• Overall, the client runs the show

SOA Characteristics

• Presentation layer can be any software capable of exchanging SOAP messages

• SOA principles dictate partitioning logic into autonomous units

• SOA units of logic are solution agnostic

Application Processing

• 80% - workstation, 20% server

• Even so, the database is often the bottleneck

• Two-tier solutions usually mean each client has a database connection

• Connections are often synchronous and persistent

• 80% processing on client may mean client programs run exclusively

• Processing with SOA is highly distributed

• Each service has explicit functional boundaries and resource requirements

• SOA allows many options for deploying services

• Enterprise solutions consist of multiple servers with sets of Web services and supporting middleware

• With SOA there is no fixed processing ratio

• Supports synchronous and asynchronous communication between service and requestors

• Messages are loaded with intelligence to support message-level context management

• Smart messaging promotes stateless and autonomous services

Technology

• The technology set for client-server applications included 4GLs like VB and PowerBuilder, RDBMSs

• The SOA technology set has expanded to include Web technologies (HTML, CSS, HTTP, etc)

• SOA requires the use of XML data representation architecture along with a SOAP messaging framework

Security

• Centralized at the Server level

• Databases manage user accounts and groups

• Also controlled within the client executable

• Security for SOA is much more complex

• Security complexity is directly related to the degree of security measures required

• Multiple technologies are required, many in WS-Security framework

Administration

• Significant maintenance costs associated with client-server

• Each client housed application code

• Each update required redistribution

• Client stations were subject to environment-specific problems

• Increased server-side demands on databases

• SOA solutions are not immune to client-side maintenance challenges

• Distributed back-end supports scalability, but new admin demands are introduced

• Management of server resources and service interfaces may require new admin tools and even a private registry

• Commitment to services and their maintenance may require cultural change in an organization

SOA vs Traditional Distributed Internet Architecture

• Muliple client-server architectures have appeared

• Client-server DB connections have been replaced with Remote Procedure Call connections (RPC) using CORBA or DCOM

• Middleware application servers and transaction monitors require significant attention

• Multi-tiered client-server environments began incorporating internet technology in 90s.

• The browser shifted 100% of application logic to the server

• Distributed Internet architecture introduced the Web server as a new physical tier

• HTTP replaced RPC protocols

• Distributed Internet application put all the application logic on the server side

• Even client-side scripts are downloaded from the server

• Entire solution is centralized

• Emphasis is on:

• How application logic is partitioned

• Where partitioned units reside

• How units of logic should interact

• Difference lies in the principles used to determine the three primary design considerations

• Traditional systems create components that reside on one or more application servers

• Components have varying degrees of functional granularity

• Components on the same server communicate via proprietary APIs.

• RPC protocols are used across servers via proxy stubs

• Actual references to other physical components can be embedded in programming code (tight coupling)

• SOAs also rely on components

• Services encapsulate components

• Services expose specific sets of functionality

• Functionality can originate from legacy systems or other sources

• Functionality is wrapped in services

• Functionality is exposed via open, standardized interface, irrespective of technology providing the solution

• Services exchange information via SOAP messages. SOAP supports RPC-style and document-style messages

• Most applications rely on document-style

• Messages are structured to be self-sufficient

• Messages contain meta information, processing instructions, policy rules

• SOA fosters reuse on a deep level by promoting solution-agnostic services

Application Processing

• Distributed Internet architecture promotes the use of proprietary communication protocols (DCOM, CORBA)

• SOA relies on message-based communication

• Messages use serialization, transmission, de-serialization of SOAP messages containing XML payloads

• RPC communication is faster than SOAP and SOAP processing overhead is a significant design issue

• Messaging framework supports a wide range message exchange patterns

• Asynchronous patterns encouraged

• Support for stateless services is supported by context management options (WS-Coordination, WS-BPEL

Technology

• Distributed Internet architecture now includes XML data representation

• XML and Web services are optional for distributed Internet architecture but not for SOA

Security

• When application logic crosses physical boundaries, security becomes more difficult

• Traditional security architectures incorporate delegation and impersonation as well as encryption

• SOAs depart from this model by relying heavily on WS-Security to provide security logic on the messaging level

• SOAP messages carry headers where security logic can be stored

Administration

• Maintaining component-base applications involves:

– keeping track of individual components

– tracing local and remote communication problems

– Monitoring server resource demands

– Standard database administrative tasks

• Distributed Internet Architecture introduces the Web server and its physical environment

• SOA requires additional runtime administration:

– Problems with messaging frameworks

– Additional administration of a private or public registry of services

Common Principles of SOA

Service oriented architecture has some common principles which include:

1. Services are reusable:Service offered by one web service provider can be reuse in a WebApp or another web service.Web services are loosely coupled components which accelerates reuse.
2. Service share a formal contract:For the services to interact they need to share a formal contract,that include:formal definition of service end point,each service operation,every input and output msg supported by each operation,rules and characteristics of the service and its operation.
3. Services are loosely coupled:Services must be designed to interact with other application or web service without tigh coupling or any type of dependency.
4. Service abstract the underlying logic:The service abstract the underlying logic of its implementation but provide access to its functionality or operation through interfaces.
5. Services are composable:The service may compose other service.
6. Services are autonomous:The service s reside inside a well defined boundary and for the successful execution of  a service it does not depend on other service.
7. Services are stateless:Service are not allowed to store the state information as it will not allow the service to be loosely coupled.
8. Service are discoverable:The service should allow thwer description to be searched and understood by humans.

comparing SOA with past architectures

When soa is compared with the past architectures it can be observed that in almost all cases like application processing,application logic,the soa is found to be better.

Comparing soa with client-server architecture:

When the application logic of client-server is considered,almost major processing is done by the client end.The server handles the data related logic and some part of the business logic.But in Soa its different where processing logic are autonomous units.Hence the overhead on client is decreased.

Similar way the application processing is a bit more in client side.since all the app logic stays in the client side,its responsible bulk processing of data.But in soa the processing is highly distributed.Each service will be having some boundary and resource requirements.

The client-server has promoted the use of many languages like visual basic,c+=.Considering soa,it has not used that much technology as it has expanded.Any existing languages can be used to deploy web services.

Comparing soa with distributed internet architecture:

In the distributed internet architecture,the emphasis is mainly given on how the application logic is partitioned or where this partitioned units should reside.The entire solution is centralized and hence the client side processing is less.The major shift related to the design is that how services exchange the information.

so even though distributed architecture emphasizes on reuse,SOA fasters the reuse and cross interoperability.

Distributed architecture gives importance to the proprietary communication protocols such as DCOM,these were efficient only when connection was made.But soa uses message based communication which makes it more efficient and helpful to deploy any web service.

When considering the security issue in the distributed internet architecture,its implemented by process like authentication and authorization.But in soa its implemented in the messaging level,where every message carries the security logic.So this preserves individual autonomy and loose coupling.

The administration in distributed architecture is done using web servers.Hence it should be developed to support scalability.But in soa the administration process is bit difficult because it needs additional run time administration.

COMPARING SOA WITH HYBRID WEB SERVICE ARCHITECTURE:

The distributed internet architecture which employs the web service is not a true soa.The distributed architectures provide point to point connections with web services.But soa along with this feature also provides support for many messaging models.Hence when a service is designed under soa keeping the design requirements in mind,the service can accommodate any number of requesters.

SOA vs distributed internet architecure

Application Logic:
The traditional distributed computing architecture is almost similar to the SOA but they are different at many points like the SOA uses the XML to communicate ie to pass messages between each other thus reducing the dependancy on any particular technology, whereasin  the distributed internet componet uses the properietary API to communicate with each other.
The distributed internet shows tight coupling as when they communicate a proxy stub is passed so that both can communicate with each other, this makes them stateful. The SOA does not have this problem, they does not require this stubs and can communicate by passing the XML messages.
Technology:
The traditional distributed computing were using the proprietary middleware like Corba, DCOM, because of this  they have got some compatibility issues, this was correted in SOA by usin SOAP messages to communicate which eliminated the use of proprietary middleware.
Technologies:
The technology behind distributed internet architecture has cheanged over time. They uses the HTML, HTTp etc. With the time webservies came into picture, SOA asically uses XML data representation and it uses SOAP for communication, Many new things has been introduced like WSDL, UDDI etc.
Security:
When it comes about distributed system security plays major role. In traditional distributed computing many things has been implemented like encryption of data. In SOA we can include the security parameters in the SOAP header itself.

comparision of SOA with past architecture

A client server architecture may consist different no of tiers: it may be single tier as well as of multi-tier.
In single-tier all the processing are assigned to the server but in two tier the data is assigned to server and the business and presentation are assigned to client.
We can compare SOA and Client Server Architecture on following base:

Application Logic:
In client-Server architecture, the main processing work resides with the client creating a monolithic architecture. This somewhat abstracted a set of business logic from the client and simplified data access programming. The presentation layer within contemporary service oriented solutions can vary.Within the server environment, options exhixts as to where application logic can reside and how it can be distributed. Additionally, it is more common within an SOA for these units of processing logic to be solution agnostic.
Application Processing:
Because more client-server application logic reside in the client component, the client workstation is responsible for the bulk of processing.The 80/20 is the rule of thumb. A two tier client server solution with large user base requires each client establish its own database connection. Each connection are persistent and communication is synchronous. Whereas, Processing in SOA is highly distributed. There is no fixed processing ratio for processing.Communication between service and requestor can  be synchronous or asynchronous.
Technology:
The emergence of client server application promoted the  use of 4GL programming Language, such as visual basic. The technology related to CS have emerged with time, each era has used different technology. The technology for SOA has emerged but not changed drastically. The technologies being used is HTML, HTTP, XML etc.
Security:
SOA has many benifits over Client Server Architecture but when it comes about security SOA introduces some problem. As SOA is distributed the security implementation not that easy but the case is not same for Client SErver. Later WS security framework has been developed to deal with the problem.
Administration:
The administration of client server architecture is problematic, with the time maintainance cost has increased dramatically for CS, also the problem with data maintainance the data may increase and as they are at one place they pose problem, the problems may also accur due to the different technologies used for each server.
SOA due its flexibility and various features does not incur any serious maintainance problem.

Principles of SOA

Following are the principles of SOA:

1. Re usability: One of the main feature of Services are that they can be reused. This helps in saving the redevelopment time and helps reducing the cost of the Application being created
2. Formal Contract: Each service need to share following formal contract, like Service Endpoint, service Operation, Every input and output for each operation, and rules and characterstics of the operation of the services. This help in communicating the services to each other and reduces the ambiguity.
3. Loose Coupling: The services are loosely coupled meaning that the services keep the information being independent of each other.
4. Abstraction: Services hide the underlying logic. They provide interface for the users to work upon. A client does not know about the underlying logic.
5. Composable: Services are composable in the sense that more than one services can be taken together to create a new service. This is done by creating a common interface to all the underlying services.
6. Autonomous: Services are meant to be autonomous that is they should not depend on other services for the execution of there services. They can provide their services on their own. There are two types of  autonomy is there: Service level autonomy and pure autonomy.
7. Stateless: The services should be stateless this is because if the services will hold the state it will not be possible for other client to discover the service. The services may remain stateful for a small period of time but this should not be for longer time interval. 
8. Discoverable: The discoverable services help to reduce the conflicts. If the services are not discoverable, there may exhist redundant services. 

SOA VS Distributed Internet Architecture

Application Logic
In case of the distributed internet architecture all the application logic resides the server side.The application logic is broken down into many component sand may reside on different server.Components on the same server communicate using proprietary APIs and components in different server communicate using RPC protocols(DIA).In case of the SOA the application logic resides on the server side which is broken down into many components.In SOA services contain one or more components and they communicate using SOAP on HTTP.

Application Processing
In case of both the DIA and the SOA the lions share of the application processing is done at the server.(as most if not all the logic resides on one or more server).For communication b/w the components RPC protocol are used.In case of SOA XML complaint SOAP msg are used.

Technology
In case of DIA client scripts,server side scripts and many web related technology are used.In SOA apart from what is used in DIA  it heavily relies on XML and wen services.


Security

Many physical layer and application layer security 

is used in in (DIA).SOA heavily depends on the 

WS-Security framework.

 
Administration
Maintaining components base applications involves

keeping track of the individual components instance

,tracing local and remote communication 

problems,monitoring the server resource demands and 

standard database and administrative tasks.In case of SOA 

run time administration is required.

Problems with msg framework can go more 

easily undetected than RPC base data exchanges,

other maintenance task include resource management.

Private registry can be used in case of the SOA.

SOA VS Client Server Architecture

Application Logic
The Client  Server architecture include fat client that does bulk of processing and data-related logic and database server lying on the server.In the case of SOA options exist regarding where the application logic can reside and how it is distributed.

Application Processing
The Client Server architecture follow 80/20 where bulk of processing is done by the client and other database access and connection pooling is done by the server .In case of SOA each service has a explicit functional boundary and resource requirement.

Technology
Client Server Arch make use of 4GL programming languages and for performance reasons make use of 3GL programming languages.They also use vendor based RDBMS packages.In case of SOA XML data representation arch along with SOAP msg framework.It makes use of HTML,CSS,HTTP etc.

Security
In case of the client server the security is centralized at the server side.But security can also be realized on the client side.SOA heavily depends on WS-security framework for security.

Administration
In client server architecture the maintenance cost are high and administration problems are also involved.
SOA is also not that immune to client-side maintenance challenges.



 

Common Principles of SOA

8 common principles of SOA are as follows :

1.Reusability

Reuse is very important within service-orientation, so that it becomes a core part of that service and design processes. Non-proprietary service technology has provided

the opportunity to maximize the reuse potential of multi-purpose logic on desire level.Services are designed to potential and frequent reuse when available and required.

2.Formal Contract

Services express their purpose and capabilities via a service contract. To define service and terms of information exchange formal contract is the best way. Contract design including that services functionality, how data types and data models are defined, and how policies lies confidential. There is a constant focus on ensuring that service contracts are optimized, granular, and standardized to ensure that the outcome should be consistent and reliable.

3. Loose Coupling

Coupling defines a connection or relationship between two things. A measure of coupling is comparable to a level of dependency.

The principle of Loose Coupling promotes the independent design and evolution of a logic for a service and implementation . There are many types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract.

Figure : Coupling represents a core design consideration that spans both intra and inter-service design.

4. Abstract underlying logic

Abstraction ties into many aspects of service-orientation. This principle emphasizes the need to hide as much of the underlying details of a service as possible.

Various forms of meta data come into the picture when we are going to assess appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort for run the service.

5. Composability

The ability to compose services is a main requirement for achieving some of the most fundamental goals of SOA.

Composibility allows logic that will help to create new service at different levels of granuality and that will be capable of participating as effective composition members. The principle of Service Composability addresses this requirement by ensuring that a variety of considerations are taken into account.

6. Service are Autonomous

The logic of this principle fully based on explicit boundaries and the principle of this service supports the extent to which other design principles can be effectively realized in real world production environments that increase a service’s reliability and behavioral predictability. And all the services within this explicit boundaries are control by them and these are independent from other service.

7. Stateless

Every service should be able to remain loosely coupled and there is no need to manage state information .Service should be design such that its statelessness maximized.Services are therefore ideally designed to remain stateful only when required.

8.Discoverable

Services should always be discoverable and also should be such that it is easily understood by humans and also service requesters so that the logic can be used.

Principles of SOA

The principles of Soa include the following:

1)Explicit boundaries:It means that everything needed by the service to provide its functionality should be passed to it when its invoked.All the access to the service should be done via the publicly exposed interfaces and there is no need of hidden assumptions to invoke the service.

2)Shared contract and schema: A contract(service description) is shared between the producer and the consumer.And this should give all the things needed for a consumer or producer to share data.

3)Policy driven:To interact with a service two conditions should me met:

a)The provider's functionality,syntax, semantics should fit consumer requirements.

b)The technical capabilities and needs must match.

4)Autonomous:The services should be autonomous meaning its relation is only with the outside world.The components should be modifiable,collaborative.So that any kind of service or combined services can be given.

5)wire formats,not programming language api's:To ensure to the fullest accessibility,a service must be accessible from any platform that supports exchange of the messages adhering to the service interface.The following conditions are met:

• All message formats are described using an open standard, or a human readable description
• It is possible to messages adhering to those schemas with reasonable effort without requiring a specific programmer’s library
• The semantics and syntax for additional information necessary for successful communication, such as headers for purposes such as security or reliability, follow a public specification or standard
• At least one of the transport (or transfer) protocols used to interact with the service is a (or is accessible via a) standard network protocol

6)Document oriented:To interact with services,data is always passed as documents.A document is explicitly modeled and its a container of data.This document shall be self descriptive.

7)Loosely coupled:It means that the services and kind of services should always be loosely coupled so that any service can be collaborated to give a new service.Some of the dimensions where loose coupling is needed are time,location,type,version,interface etc.

8)Standard-compliant:It clearly indicates that soa approach should be on standards than any owned api's or formats.This principle clearly indicates the use of relying on standards than any other thing.

9)Vendor independent:No architectural pattern should depend on the vendor particular.Because this always affects interoperability and portability.This indicates that any service can be built only on standards not worrying about product.

client server architecture vs soa

CLIENT SERVER ARCHITECTURE vs SOA

	Client server architecture	Service Oriented Architecture
Application logic	Places the majority of application logic into client software.	The application logic resides completely on the service provider, sometimes provider can also be service requester.
Application processing	Bulk of processing(about 80%) is on the client side. Processing ratio is 80/20 (client/server)	Processing is highly distributed. No fixed processing ratio
Technology	Visual basic and powerbuilder ,c++,oracle Sybase at the backend	Web technologies(HTML,CSS,HTTP) and  XML with SOAP messaging framework
Security	Security controlled within client executable, OS level security can also be incorporated.	WS-security framework
Administration	Larger maintenance cost  due to distributed application cost	Less maintenance cost, if  web service need to be scaled to large  group then it incurs large maintenance cost

Principles of SOA

Principles of SOA

 1) Services are reusable

                Services are designed in such a way that they should be reused in future,

so that activities concerned with development of redundant services can be minimised

reuse can of inter-application interoperability, composition, creation of cross cutting

or utility services, more generic the service is more the reuse.

2)Services are share a formal contract

                A formal contract need to be shared between the service requestors and the service providers, these contracts explain the how a service may go about accomplishing a particular task. These contracts define service endpoint, operation, input & output supported by each operation, rules and characteristics of a service.

3)Services are loosely coupled

                If services to be composed with others so as to develop a inter application or cross cutting applications these services need to be loosely coupled with each other, services should interact with each other with some predefined parameters but should be independent of each other.

4)Services abstract underlying logic

                Services act as black boxes hiding details from outside world but exposes only those that need for services  to communicate with each other  

5)Services are composable

                If we need to develop some cross cutting applications then services should be able to be composed with others services ,this is another form of reuse.

6)Services are autonomous

                The logic the service provides is confined within a boundary and service has control only within the boundary. Types of autonomy

  1) Service-level autonomy.

  2)Pure autonomy.        

7)Services are stateless

                If we want services to be loosely-coupled then they should not maintain any state information.

8)Services are discoverable

                To implement the principle of reuse services need to discovered in its first place, this also avoids creation  of redundant logic