Wednesday, 18 May 2011
mtechsoa2011: Principles of SOA
mtechsoa2011: Principles of SOA: "Principles of SOA 1) Services are reusable Services are designed in such a way that they should be reused in future, s..."
mtechsoa2011: client server architecture vs soa
mtechsoa2011: client server architecture vs soa: "CLIENT SERVER ARCHITECTURE vs SOA Client server architecture Service Oriented Architectu..."
Saturday, 7 May 2011
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.
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.
Thursday, 5 May 2011
SOA vs Hybrid Web service architecture
Web services of hybrid architecture having an integration layer present using for synchronous communication with the help of SOAP (complaint integration channels), actually these web services encapsulating components of different services or application.
Intigration channels are basically utilized in integration architectures to provide communication with other applications, third party utilities or partners.
This architecture is simply a distributed internet architecture that uses web services but can not take it as a service oriented architecture. SOA defines design requirements for web services as well a support them with concern of messaging models weather synchronous or asynchronous.
In SOA every service having vast scope that is clearly specified and that can accomodate a large number of requestors, current as well as future.
Only SOA architecture having tangible characteristics and variable capabilities and made for for collectively participate in number of different bussiness processes.
Tuesday, 3 May 2011
Common Principles of Service-Orientation
The common set of principles mostly associated with service-orientation are listed below:
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:
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.
- 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.
Wednesday, 27 April 2011
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
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,
- how application logic is partitioned.
- where the partitioned units of processing logic should reside.
- 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.
Subscribe to:
Posts (Atom)