CSC/ECE 517 Fall 2009/wiki2 16 am

From Expertiza_Wiki
Jump to navigation Jump to search

Service Oriented Architecture

Service-Oriented Architecture (SOA) can be defined as an Architectural design pattern that concerns itself with defining loosely-coupled relationships between producers and consumers. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.

Rather than defining an Application Programming Interface -- API or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

The need for Service-Oriented Architecture -- SOA

The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA.

Design patterns

A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code.

  • It is a description or template for how to solve a problem that can be used in many different situations.
  • Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved.
  • Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation.
  • Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Role of design patterns in SOA

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions.

Categories of SOA Design Patterns

Category Objective
Foundational Inventory Patterns These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
Logical Inventory Layer Patterns These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
Inventory Centralization Patterns These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
Inventory Implementation Patterns These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
Inventory Governance Patterns These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
Foundational Service Patterns These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
Service Implementation Patterns These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
Service Security Patterns These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
Service Contract Design Patterns These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
Legacy Encapsulation Patterns These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
Service Governance Patterns These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
Capability Composition Patterns These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
Service Messaging Patterns These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
Composition Implementation Patterns These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
Service Interaction Security Patterns These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
Transformation Patterns These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
Common Compound Design Patterns These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.


SOA design patterns and traditional design patterns Gang of Four -- GoF patterns

Object orientated (OO) concepts such as inheritance, encapsulation, and polymorphism could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

Differences between SOA design patterns and traditional patterns

  • Aim of design patterns:
    SOA patterns are more about Modeling, Design, Architecture
    GoF patterns are about Modeling, Design, Architecture and Programming
  • What the design patterns expose:
    SOA patterns expose services
    GoF patterns expose methods
  • Level of granularity that the design patterns provide:
    SOA patterns exhibit business-level granularity
    GoF patterns exhibit component/object-level granularity
  • Interaction provided in the patterns:
    SOA patterns interact at the service-level, inter-service via service requests
    GoF patterns interact component/object-level, inter-objects/components via method calls
  • Standards for patterns:
    SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
    GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.

Similarities between traditional design patterns and the SOA design patterns

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

  • Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)

    • Capability Composition: These patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

    Composite: The composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

  • Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)

    • Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core service logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

    Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library, wrap a poorly-designed collection of APIs with a single well-designed API.

  • Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)

    • Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

    Adapter: The adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

  • Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)

    • Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

    Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

  • Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)

    • Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

    Bridge: The bridge is a design pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

    Resources

    Abbreviations

    Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_16_am&oldid=24505"