NEWS NEWS
Return to Home Page

Introduction to
Service-Orientation
    Services (Part I)
    Services (Part II)
    The Service-Orientation
Design Paradigm
    Origins and Influences of Service-Orientation (Part I)
    Origins and Influences of Service-Orientation (Part II)

Service-Orientation
Design Principles
    Standardized Service Contracts
    Service Loose Coupling
    Service Abstraction
    Service Reusability
    Service Autonomy
    Service Statelessness
    Service Discoverability
    Service Composability
    Service-Orientation and Interoperability

Effects of Service-Orientation on the Enterprise
    Service-Orientation and the Concept of "Application"
    Service-Orientation and the Concept of "Integration"
    The Service Composition

Service-Orientation
in the Real World
    Life Before
Service-Orientation (Part I)
    Life Before
Service-Orientation (Part II)
    The Need for
Service-Orientation (Part I)
    The Need for
Service-Orientation (Part II)
    Challenges Introduced by Service-Orientation (Part I)
    Challenges Introduced by Service-Orientation (Part II)
    Additional Considerations

Resources
    SOA Book Series
    SOA Training & Certification
    Free SOA Principles Poster
    Notification
    SOAPatterns.org
    WhatIsSOA.com
    SOA Visio Stencil


SThe Need for Service-Orientation (Part II)

Home > Service-Orientation in the Real World > The Need for Service-Orientation (Part II)

...continued from previous page
Reduced Amounts of Application-Specific Logic

Increasing the amount of solution logic not specific to any one application or business process decreases the amount of required application-specific logic. This blurs the lines between standalone application environments by reducing the overall quantity of standalone applications. (See the Service-Orientation and the Concept of "Application" page.)


Figure: Business Process A can be automated by either Application A or Service Composition A. The delivery of Application A can result in a body of solution logic that is all specific to and tailored for the business process. Service Composition A would be designed to automate the process with a combination of reusable services and 40% of additional logic specific to the business process.

Reduced Volume of Logic Overall

The overall quantity of solution logic is reduced because the same solution logic is shared and reused to automate multiple business processes, as shown in the following figure.


Figure: The quantity of solution logic shrinks as an enterprise transitions toward a standardized service inventory comprised of “normalized” services.

Inherent Interoperability

Common design characteristics consistently implemented result in solution logic that is naturally aligned. When this carries over to the standardization of service contracts and their underlying data models, a base level of automatic interoperability is achieved across services. (See the Service-Orientation and the Concept of "e;Integration"e; page.)


Figure: Services from different parts of a service inventory can be combined into new compositions. If these services are designed to be intrinsically interoperable, the effort to assemble them into new composition configurations is significantly reduced.

The Prentice Hall Service-Oriented Computing Series from Thomas Erl
Home    SOA Books    SOA Magazine    SOA School    What is SOA?    SOA Patterns    SOA Methodology    SOA Glossary    SOA Specs    Legal
Copyright © 2007-2009 SOA Systems Inc.