CSC/ECE 517 Fall 2009/wiki2 16 agummad: Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
Service-oriented computing represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design pattern catalogs, pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks. The article weighs in the salient features the design patterns of Service Oriented Architecture | Service-oriented computing represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design pattern catalogs, pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks. The article weighs in the salient features the design patterns of Service Oriented Architecture | ||
Introduction | <h1>Introduction</h1> | ||
SOA is essentially a collection of services. These services operate in the general sense by effectively communicating with each other. This communication could fall within a broad range of possibilities from exchanging information in the form of data or coordinating and interoperating with each other to implement a combination service. Thus there must be standardized ways that facilitates communication between such services. | SOA is essentially a collection of services. These services operate in the general sense by effectively communicating with each other. This communication could fall within a broad range of possibilities from exchanging information in the form of data or coordinating and interoperating with each other to implement a combination service. Thus there must be standardized ways that facilitates communication between such services. | ||
These services are now architected or rather combined in such a way that they encourage interoperability, loose coupling and extensibility of the services that play their respective roles as ingredients. | These services are now architected or rather combined in such a way that they encourage interoperability, loose coupling and extensibility of the services that play their respective roles as ingredients. | ||
Principle of Operation | <h1>Principle of Operation<h1> | ||
The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. A service provider can also be a service consumer. | The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. A service provider can also be a service consumer. | ||
Extending this principle, SOA attempts to fabricate an architectural model that aims to enhance the efficiency, and productivity of an enterprise. They do this by positioning services as the primary means through which solution logic is represented in support of the realization of the strategic goals associated with service-oriented computing [1]. | |||
Within an SOA, services that make up blocks of the architecture comprise of unassociated, | Within an SOA, services that make up blocks of the architecture comprise of unassociated, loosely coupled units of functionality. Each service implements one specific one action, for example automated filling in of applications or viewing of a bank statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, a more generic approach for communication is used. These services use defined protocols that describe how services pass and parse messages, using description meta-data We will explore the importance of meta data in a following section. | ||
The developer now associates software functionality - the services in a non-hierarchical arrangement (in contrast to a | The developer now associates software functionality - the services in a non-hierarchical arrangement (in contrast to a class hierarchy) using a software tool that contains a complete list of all available services, their characteristics, and the means to build an application utilizing these sources. | ||
Importance of Meta-Data | <h2>Importance of Meta-Data</h2> | ||
For all these layers of functionality and different services to inter operate seamlessly, one would rely on | For all these layers of functionality and different services to inter operate seamlessly, one would rely on meta data to describe not only the characteristics of each of these services, but also the data that flows between them and makes them work. For this purpose initial implementations used XML extensively in SOA to structure data as it flows from one service to another .In later implementations, WSDL describe the services themselves, while SOAP describes the communications protocols. Based on the history of working with various description languages to facilitate metadata transfer between different services, the following are the ideal criteria identified for metadata, | ||
The metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity. | The metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity. | ||
The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort. | The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort. | ||
The goal of having an SOA is to allow users to combine together, linearly or otherwise fairly large chunks of functionality from existing services to form ad hoc applications. The larger the chunks of the functionality, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the | The goal of having an SOA is to allow users to combine together, linearly or otherwise fairly large chunks of functionality from existing services to form ad hoc applications. The larger the chunks of the functionality, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the nth application is low, as all of the software required already exists to satisfy the requirements of other applications. | ||
As a form of technology architecture, an SOA implementation can be a combination of a number of technologies, products, APIs, supporting infrastructure extensions. The actual face of a deployed service-oriented architecture is unique within each enterprise; however it is typified by the introduction of new technologies and platforms that specifically support the creation, execution, and evolution of service-oriented solutions. As a result, building a technology architecture around the service-oriented architectural model establishes an environment suitable for solution logic that has been designed in compliance with service-orientation design principles.
| As a form of technology architecture, an SOA implementation can be a combination of a number of technologies, products, APIs, supporting infrastructure extensions. The actual face of a deployed service-oriented architecture is unique within each enterprise; however it is typified by the introduction of new technologies and platforms that specifically support the creation, execution, and evolution of service-oriented solutions. As a result, building a technology architecture around the service-oriented architectural model establishes an environment suitable for solution logic that has been designed in compliance with service-orientation design principles.
| ||
SOA and Webservices: | SOA and Webservices: | ||
Modern | Modern web services implement a service-oriented architecture. Web services in their general mode of operation, attempt to make typical services, serving as functional building-blocks for a larger combination, accessible over standard Internet protocols. Since the operation is over-the-internet, the combination is independent of platforms and programming languages. | ||
Each SOA building- block service can play one or both of the following roles: | Each SOA building- block service can play one or both of the following roles: | ||
Service Provider
The service provider creates a | Service Provider
The service provider creates a web service He would also publish its interface and access information to the service registry. Each provider must then decide which services to expose and makes decisions about use charges, security easy availability etc. | ||
Service requester
The service requester or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services. Which service the service-requesters need, they have to take it into the Brokers, then bind it with respective service and then use it. They can access multiple services, if the service provides multiple services.. | Service requester
The service requester or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services. Which service the service-requesters need, they have to take it into the Brokers, then bind it with respective service and then use it. They can access multiple services, if the service provides multiple services.. | ||
<h1>SOA Patterns</h1> | |||
Significance of Patterns | <h2>Significance of Patterns</h2> | ||
Patterns in general provide a proven solution to a common problem that is individually documented in a consistent format and usually as part of a larger collection[1] Design pattern are now a fundamental part of architecting various IT related services. In its simplest sense , these patterns provide common reusable ways to solve general problems that come up in implementing/ IT products by virtue of better design. Patterns in the IT world that revolve around the design of automated systems are referred to as design patterns. | Patterns in general provide a proven solution to a common problem that is individually documented in a consistent format and usually as part of a larger collection[1] Design pattern are now a fundamental part of architecting various IT related services. In its simplest sense , these patterns provide common reusable ways to solve general problems that come up in implementing/ IT products by virtue of better design. Patterns in the IT world that revolve around the design of automated systems are referred to as design patterns. | ||
Thus, an IT design pattern is not a finished end – of – the – line design that can be transformed directly into code. Rather, It provides a description or a template about how to solve a problem, and therefore this template that can be used in many different situations.
Design patterns are helpful because they represent field-tested and industry – accepted solutions to common design problems, and since their quality is prove, their consistent application tends to naturally improve the quality of system designs. | |||
represent field-tested and industry – accepted solutions to common design problems, and since their quality is prove, their consistent application tends to naturally improve the quality of system designs. | * Provide a methodology to organize design knowledge and decision making intelligence | ||
Provide a methodology to organize design knowledge and decision making intelligence | * By virtue are repeatable templates which can be put to use by most IT professionals involved with design. | ||
By virtue are repeatable templates which can be put to use by most IT professionals involved with design. | * Are extensively used to ensure consistency in how IT systems are designed and built | ||
Are extensively used to ensure consistency in how IT systems are designed and built | * Can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied) | ||
Can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied) | * Are usually flexible and optional (andopenly document the impacts of their application and even suggest alternative approaches) | ||
Are usually flexible and optional (andopenly document the impacts of their application and even suggest alternative approaches) | * Enrich the vocabulary of a given IT field because each pattern is given a meaningful name | ||
Enrich the vocabulary of a given IT field because each pattern is given a meaningful name | |||
These patterns are not specific to any language, vendor, platform or imdustry, these are simple techniques that help in overcoming well documented problems faced while attempting to achieve the strategic goals associated with SOA. The SOA design patterns collectively “master pattern language”. This allows a framework where patterns can be effectively combined in various combinations and sequences. We highlight key design patterns for the SOA architecture. |
These patterns are not specific to any language, vendor, platform or imdustry, these are simple techniques that help in overcoming well documented problems faced while attempting to achieve the strategic goals associated with SOA. The SOA design patterns collectively “master pattern language”. This allows a framework where patterns can be effectively combined in various combinations and sequences. We highlight key design patterns for the SOA architecture enumerated in [3]. | ||
Patterns for Collection of Services | <h2>Patterns for Collection of Services</h2> | ||
A service inventory represents a collection of independently developed and standardized services, These services according to service orientation such that they become interoperable. This architecture allows a pool of services that can be used to assemble and augment compositions of services repeatedly. | A service inventory represents a collection of independently developed and standardized services, These services according to service orientation such that they become interoperable. This architecture allows a pool of services that can be used to assemble and augment compositions of services repeatedly. | ||
Inventory Boundary Patterns | <h2>Inventory Boundary Patterns</h2> | ||
The Enterprise Inventory and Domain Inventory Design pattern provides alternative approaches to determine the scope for a service inventory. The Enterprise Inventory pattern focuses on establishing an inventory with an enterprise wide scope. In contrast the Domain Inventory Patterns use an approach wherein the enterprise is divided into segments, each of which represents a meaningful scope for the service inventory, allowing neighbors to evolve independently. | The Enterprise Inventory and Domain Inventory Design pattern provides alternative approaches to determine the scope for a service inventory. The Enterprise Inventory pattern focuses on establishing an inventory with an enterprise wide scope. In contrast the Domain Inventory Patterns use an approach wherein the enterprise is divided into segments, each of which represents a meaningful scope for the service inventory, allowing neighbors to evolve independently. | ||
Inventory Structure Pattern | <h2>Inventory Structure Pattern</h2> | ||
The Services layer pattern is used to further organize a service inventory into a set of logical layers each of which is based on a different classification of service. To support and extend the structure of a service inventory architecture, other design patterns are used. | The Services layer pattern is used to further organize a service inventory into a set of logical layers each of which is based on a different classification of service. To support and extend the structure of a service inventory architecture, other design patterns are used. | ||
Patterns for Service Design: Each service within the architecture exists as a stand alone software but then are fully geared to participate in larger aggregation of services. Numerous challenges exists especially when trying to maintain a loose coupled arrangement of services. | Patterns for Service Design: Each service within the architecture exists as a stand alone software but then are fully geared to participate in larger aggregation of services. Numerous challenges exists especially when trying to maintain a loose coupled arrangement of services. | ||
| Line 52: | Line 51: | ||
Challenges in adopting SOA | <h1>Challenges in adopting SOA</h1> | ||
Albeit | Albeit the advantages of SOA, the adoption of its architectural and design prociples are not trivial. Some of the challenges that exist are enumerated below. | ||
One | * One of the common challenges faced involves managing messages generated by each service. SOA-based environments can include many services that exchange messages to perform tasks. * * * Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact is a complicated task. | ||
Another challenge is the lack of testing in SOA space. There are no tools sophisticated enough to provide testability of all the services in a typical architecture | * Another challenge is the lack of testing in SOA space. There are no tools sophisticated enough to provide testability of all the services in a typical architecture | ||
Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when the capabilities of the application are exposed as services that can be used by other applicationsAs SOA and the | * Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when the capabilities of the application are exposed as services that can be used by other applicationsAs SOA and the WS-* specifications practitioners constantly expand, update and refine their output, there is a shortage of skilled people to work on SOA-based systems, including the integration of services and construction of services infrastructure. | ||
SOA efforts are routinely initiated by internal IT delivery organizations, and some of these improperly introduce concepts to the business so it remains misunderstood. The adoption starts meeting IT delivery needs instead of those of the business, so the result is an organization with superlative laptop provisioning services, instead of one that can quickly respond to market opportunities. Business Leadership also becomes convinced that the organization is executing on SOA well. | SOA efforts are routinely initiated by internal IT delivery organizations, and some of these improperly introduce concepts to the business so it remains misunderstood. The adoption starts meeting IT delivery needs instead of those of the business, so the result is an organization with superlative laptop provisioning services, instead of one that can quickly respond to market opportunities. Business Leadership also becomes convinced that the organization is executing on SOA well. | ||
Criticisms of SOA | <h1>Criticisms of SOA</h1> | ||
Most of the criticisms | Most of the criticisms of SOA draw from the assumption by most people that SOA is just another term for Web Services. For example, some critics of SOA observe that adoption of SOA strategies results in introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC), applications could run slower and require more processing power, increasing costs. | ||
Another factor critical to the development of SOA is that WS-* standards and protocols (WSDL and the like) are still evolving (e. g., transaction, security), and therefore the adoption of SOA may be introducing potential risks | * Another factor critical to the development of SOA is that WS-* standards and protocols (WSDL and the like) are still evolving (e. g., transaction, security), and therefore the adoption of SOA may be introducing potential risks | ||
Some critics also feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc). | * Some critics also feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc). | ||
The ability to easily modify systems is sometimes omitted from IT system design. Many systems, including SOAs, hard-code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace. | * The ability to easily modify systems is sometimes omitted from IT system design. Many systems, including SOAs, hard-code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace. | ||
References | References | ||
1. www.socpatterns.com – Edited by Thomas Erl | |||
www/whatissoa.com – Edited by Thomas Erl | 2. www/whatissoa.com – Edited by Thomas Erl | ||
Introducing SOA Design Patterns – Thomas Erl | 3. Introducing SOA Design Patterns – Thomas Erl | ||
Wikipedia.com | 4. Wikipedia.com | ||
| Line 76: | Line 75: | ||
A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services | A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services | ||
WSDL: | WSDL: Web Service Description Language | ||
SOAP: | SOAP: Simple Object Access Protocol | ||
metadata : | metadata : Data about data | ||
RPC : Remote Procedure Call | |||
Revision as of 02:38, 10 October 2009
Abstract
Service-oriented computing represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design pattern catalogs, pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks. The article weighs in the salient features the design patterns of Service Oriented Architecture
Introduction
SOA is essentially a collection of services. These services operate in the general sense by effectively communicating with each other. This communication could fall within a broad range of possibilities from exchanging information in the form of data or coordinating and interoperating with each other to implement a combination service. Thus there must be standardized ways that facilitates communication between such services. These services are now architected or rather combined in such a way that they encourage interoperability, loose coupling and extensibility of the services that play their respective roles as ingredients.