CSC/ECE 517 Fall 2009/wiki2 16 am

From Expertiza_Wiki
Jump to navigation Jump to search

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.

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.

Example for Traditional Design

Traditional Design

Example for SOA Design

SOA based Design

Design patterns

A design pattern is a general reusable solution to a commonly occurring problem in software design.

  • 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 enable the creation of effective service-oriented solutions, but also to provide 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 oriented(OO) concepts such as inheritance, encapsulation, and polymorphism that 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)

    • These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

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

    • A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

    Case study example

    For example, Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independent and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independently but also allow the service facade component to utilise its logic.

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

    • These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

    Case study example

    If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functionality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

  • Non-Agnostic Context (SOA) is similar to Mediator Pattern (Traditional)

    • Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

    Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

    SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

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

    • 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 services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

    Case study example

    Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the problem that arises is that the Data Controller is a standalone Java EJB(Enterprise JavaBeans), while the Fines and Evaluation Service is standardized on the web services technology framework(XML and WSDL schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independently from its underlying service logic and can be used as a web service.


    Resources

    Abbreviations

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