Vp

Understanding Service-Oriented Architecture

by David Sprott and Lawrence Wilkes
CBDI Forum
January 2004

Summary: Gives a concise explanation of service-oriented architecture, what it is, and how it affects what architects, CIOs, project managers, business analysts, and lead developers do.

Contents
Introduction
Principles and Definitions
SOA Basics
Process Matters
Architectures
The Service Architecture
The SOA Platform
The Enterprise SOA

Summary
Introduction
It seems probable that eventually most software capabilities will be delivered and consumed as services. Of course they may be implemented as tightly coupled systems, but the point of usage—to the portal, to the device, to another endpoint, and so on, will use a service-based interface. We have seen the comment that architects and designers need to be cautious to avoid everything becoming a service. We think this is incorrect and muddled thinking. It might be valid right now given the maturity of Web Service protocols and technology to question whether everything is implemented using Web services, but that doesn't detract from the need to design everything from a service perspective. The service is the major construct for publishing and should be used at the point of each significant interface. service-oriented architecture allows us to manage the usage (delivery, acquisition, consumption, and so on) in terms of, and in sets of, related services. This will have big implications for how we manage the software life cycle—right from specification of requirements as services, design of services, acquisition and outsourcing as services, asset management of services, and so on.
Over time, the level of abstraction at which functionality is specified, published and or consumed has gradually become higher and higher. We have progressed from modules, to objects, to components, and now to services. However in many respects the naming of SOA is unfortunate. Whilst SOA is of course about... [continues]

Read full essay