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


Service-Orientation and the Concept of "Integration"

Home > Effects of Service-Orientation on the Enterprise > Service-Orientation and the Concept of "Integration"

When we revisit the idea of a service inventory consisting of services that have, as per our service-orientation principles, been shaped into standardized and (for the most part) reusable units of solution logic, we can see that this can challenge the traditional perception of "integration."

In the past, integrating something implied connecting two or more applications or programs that may or may not have been compatible. Perhaps they were based on different technology platforms or maybe they were never designed to connect with anything outside of their own internal boundary. The increasing need to hook up disparate pieces of software to establish a reliable level of data exchange is what turned integration into an important, high profile part of the IT industry.


Figure: The traditional integration architecture, comprised of two or more applications connected in different ways to fulfill a new set of automation requirements (as dictated by the new Business Process G).

Services designed to be “intrinsically interoperable” are built with the full awareness that they will need to interact with a potentially large range of service consumers, most of which will be unknown at the time of their initial delivery. If a significant part of our enterprise solution logic is represented by an inventory of intrinsically interoperable services, it empowers us with the freedom to mix and match these services into infinite composition configurations to fulfill whatever automation requirements come our way.

As a result, the concept of integration begins to fade. Exchanging data between different units of solution logic becomes a natural and secondary design characteristic. Again, though, this is something that can only transpire when a substantial percentage of an organization’s solution logic is represented by a quality service inventory. While working toward achieving this environment, there will likely be many requirements for traditional integration between existing legacy systems but also between legacy systems and these services.


Figure: A new combination of services is composed together to fulfill the role of traditional integrated applications.

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.