Best Practices for Adopting SOA

SOA Overview

What is SOA?
Service Oriented Architecture
Service
System capabilities that provide access to functions and data are
appropriately exposed to other components (applications, devices,
networks, etc.)

Oriented
Uses open interoperability protocols

Architecture
In its purest form, its the connection of systems (simple or complex)

What Has Slowed True SOA Implementations?

Proprietary tools
Lack of universally accepted protocols
Enterprise governance less emphasized
Legacy roadblocks
Result is StovePipe Integration
Application

Application

Application

Application

Application

Application

What is Different Now?

Numerous tools and open standards:
Internet, XML, SOAP, UDDI, WSDL, JMS, .NET, etc
General acceptance of standards
Architecturally integrated Web Services, MOM, and RMI
architectures are now more achievable
Unprecedented urgency to share data

A Practical Step
Enterprise Governance being the objective:
Leverage the legacy by decoupling point-to-point
relationships and extending services to external requests
Monolithic legacy applications can be become service
providers
Exposing services is more important than how
Service Orientation is infectious

Integration of Services
Application

Application

Application

Application

Business Rules

Publish
Application Application

Inquire
Application Application

Data
Transformation Rules
Application
Application

Application

Application

The integration of services becomes the Service Bus,

or what we like to call the Interoperability Hub

Walk Then Run

Start with simple document-oriented exchanges
Enhance through service aggregation
Prudently evolve toward document-oriented Publish/Subscribe
and Orchestrated relationships
Business Function/Service Aggregation
Transformation/Routing Services
Orchestrated Transactions
and Event Driven Services

SOA Opens the Architecture

As external services development spreads and matures within
an environment, the legacy application components become
open.
- and therefore New application development will begin to be based more on
the integration of services, rather than linking of components
and databases.
Application

Publish

Application

Business Rules

Application

Inquire
Application

Data Transformation Rules

Application

Application

Troy Holmes

Implementing SOA

How Services Make Applications Open

SOA is a service based architecture that utilizes open,
standards-based Web Services
All applications can speak XML without requiring proprietary
third party products
SOA breaks down the walls of conventional software design, by
enabling reuse of existing applications.
SOA can be used to encapsulate legacy business logic and
provide functionality to a larger user base.

How Services Make Applications Open

By wrapping services with SOA, agencies will be building the
groundwork for information sharing throughout the
government.
Building new solutions for agencies becomes faster and easier
Existing services can be quickly combined into new applications, that
provide enhanced functionality
The applications are exposed in a standardized format

It becomes the a la carte of application processes

How Services Make Applications Open

In the past applications were integrated in a tightly coupled fashion which led to a
frail implementation
By providing loose coupling to application processes, the consumer is not aware of
the internal implementation, and therefore is protected from changes by the producer.

Database

Database

Consumer

Producer
API

Data Access
Tier

API

Business
Tier

Data Access
Tier

How Services Make Applications Open

In the past applications were integrated in a tightly coupled fashion which led to a
frail implementation
By providing loose coupling to application processes, the consumer is not aware of
the internal implementation, and therefore is protected from changes by the producer.

Database

Database
Generic
Service

Consumer
API

Data Access
Tier

Producer
API

Business
Tier

Data Access
Tier

How Services Make Applications Open

An agency can quickly adapt to new methods of communication
New implementations can be added faster and more reliably in a SOA environment
New customers send messages based on an agreed contract between the producer and
consumer
The implementation is independent of the producer which enables multiple views of
information without impacting legacy applications
Business Logic

Interface Facade

Business
Application

Service

Producer
Secure Business Applications

Customizable Presentation Tier

Message
Contract

XML

Consumer

How Agencies are Integrating Stovepipe

Applications
Legacy
Mainframes

Todays Architecture

Data
Data

Workstation

Application
Servers
Application
Servers
Web Servers

Data

Data
Warehouse
Data
Marts

Report
Server

Data
Marts

Technologies Used for Integration

Marts

Marts
Warehouse

Marts

Message Oriented Middleware

MOM
(Hub and Spoke)

Marts

Data Warehousing

Object

XML

Service

Legacy

Web Services

Object

Remote Method Invocations

RMI

Roadmap to SOA
Start by creating services around existing
processes within applications

Application

Define current business processes within

existing applications
Create course grain services that satisfy
particular business processes

Make these services available to the

internal agency
Expose these services to external agencies
via an Enterprise Interoperability Hub
(Service Bus)

Business
Process

Business
Process

Business
Process

Service

Service

Service

XML

XML

XML

Roadmap to SOA
Application

Application

Application

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Service

Service

Service

Service

Service

Service

Service

Service

XML

XML

XML

XML

XML

XML

XML

XML

Moving from Stovepipes . . .

Roadmap to SOA
Application

Application

Application

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Business
Process

Service

Service

Service

Service

Service

Service

Service

Service

Enterprise Interoperability Hub

Transformation

XML

XML

XML

Transformation

Transformation
XML
XML

XML

XML

Moving from Stovepipes . . . To Shared Services

XML

XML

Roadmap to SOA
Enterprise Interoperability Hub
The next step is to provide a view of the agency to external customers via
an Enterprise Interoperability Hub
The Hub will become the mechanism to represent services to external
agencies.
SOAP Service
Portal Service

External Agency
Service

Enterprise Interoperability Hub

Request

Data Service

Transformation/Routing Services
Orchestrated Transactions
and Event Driven Services

MOM Service

New Application
Service

Roadmap to SOA
Legacy
Mainframes

Todays Architecture

Data
Data

Workstation

Application
Servers
Application
Servers
Web Servers

Data

Data
Warehouse
Data
Marts

Report
Server

Data
Marts

Roadmap to SOA

Future Architecture
Legacy
Mainframes

Exposed
Service

Data

Exposed
Service

Workstation

Enterprise
Interoperability
Hub
(Service Bus)

Data

Exposed
Service
Exposed
Service

Application
Servers
Application
Servers

Exposed
Service

Web Servers

Data

Data
Warehouse
Data
Marts

Report
Server

Data
Marts

Roadmap to SOA

Future Architecture
Legacy
Mainframes

Exposed
Service

Data

Exposed
Service

Workstation

Enterprise
Interoperability
Hub
(Service Bus)

Data

Exposed
Service
Exposed
Service

Application
Servers
Application
Servers

Exposed
Service

Web Servers

Data

Data
Warehouse
Data
Marts

Report
Server

Data
Marts

Jeff Simpson

SOA Best Practices

What Attendees Will Learn

Best practices for the implementation of service-oriented
architectures (SOA) and web services
How to design a roadmap to consolidate and rationalize diverse
constituent portals, websites, and web services with a common
architecture, security framework, and user interface
Practical suggestions for using resources from legacy systems
with newer applications

Implementation Best-Practices
What is the Use-Case?
Plan for reuse
Transactions
Tuning and Management

Plan for Reuse

Scalability
Reliability
Deployment
Documentation

Pick the Right Interface

Web Services and XML provide best interoperability but not the
best performance
Web Services are not always the right answer
Maybe multiple interfaces? (WS, RMI, JMS, MQ, CORBA,
etc.)

To UDDI or to Not UDDI ?

When do you publish your WSDL?
The defacto standard email

UDDI.org
Excellent source of
information and resources
regarding UDDI, the
specification, and the future
of WebServices discovery

WebService Management
What does it provide?
Quality of Service (QoS)
Service Level Agreements (SLAs)

Registry Services
When to involve the technology?

Rationalization Roadmap
Service Rationalization or Portal Rationalization?
Is there a difference?
A portal or portlet does not equal a WebService

Composite Application or Business Process Rationalization?

Service Rationalization
Creating a new service contract or API that fronts multiple
legacy implementations
Enables service consolidation
Terrific path to drastically reducing TCO

Service Fabric

adaptor
Legacy
Service A

Rationalized
Service
router

adaptor
Legacy
Service B

adaptor
Legacy
Service C

Portal Rationalization
Collapsing the web interfaces from multiple systems into a
single portal by having each interface be its own portlet within
the portal

Composite Applications
Business Process Rationalization
A combination of Service and Portal Rationalization where, through a
workflow engine, we create a new composite application and new
interface that leverages existing IT assets in a new unified business
process

Integrating the Integration

Process / Data Integration

App Server

SOA Fabric
WebService Enabled

Broker
(BEA, WebMethods or Tibco)
Broker
WebService Enabled
WebService Enabled

WebService Enabled

WebService Enabled

PeopleSoft
HR System 1

HR System 2

HR System 3

Adapting Legacy System for SOA

Fronting with a WebService
Can be done with one of many technologies - Apache Axis, Systinet,
J2EE Servlet containers (Tomcat, JBoss, WebSphere, WebLogic), etc
Look to using a WebService Management layer

Utilizing a Messaging system (ESB Flavor 1)

MQ Series, Tibco, one of many JMS providers

Utilizing Traditional EAI connectors (ESB Flavor 2)

Vitria, webMethods, SeeBeyond, etc.