Best Practices for Adopting SOABest Practices for Adopting SOA

SOA OverviewSOA Overview

What is SOA?

Service Oriented ArchitectureService Oriented Architecture

ServiceServiceSystem capabilities that provide access to functions and data are appropriately exposed to other components (applications, devices, networks, etc.)

OrientedOrientedUses “open” interoperability protocols

ArchitectureArchitectureIn its purest form, it’s 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

Application

ApplicationApplication

Application

Result is StovePipe IntegrationResult is StovePipe Integration

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

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

Enterprise Governance being the objective:Enterprise Governance being the objective:

Integration of Services

The integration of services becomes the Service Bus,or what we like to call the Interoperability Hub

Application

ApplicationApplication

Application

Application Application

Application

ApplicationApplication

Application

Application Application

Business RulesBusiness Rules

Data Transformation RulesData Transformation Rules

Publish Inquire

Walk Then Run

Start with simple document-oriented exchanges

Business Function/Service AggregationBusiness Function/Service Aggregation

Transformation/Routing ServicesTransformation/Routing Services

Orchestrated Transactionsand Event Driven ServicesOrchestrated Transactionsand Event Driven Services

Prudently evolve toward document-oriented Publish/Subscribe and Orchestrated relationships

Enhance through service aggregation

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

ApplicationApplication

Application

Application Application

Business RulesBusiness Rules

Data Transformation RulesData Transformation Rules

Publish Inquire

Troy Holmes

Implementing SOAImplementing 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.

BusinessTier

Consumer Producer

Data AccessTier

Data AccessTier

Database

API

Database

API

GenericService

Database

API

Database

API

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.

BusinessTier

Consumer Producer

Data AccessTier

Data AccessTier

Secure Business Applications

How Services Make Applications Open

An agency can quickly adapt to new methods of communication

BusinessApplication

Service

Business Logic Interface Facade

Producer

XML

Customizable Presentation Tier

Consumer

Message

Contract

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

?

How Agencies are Integrating Stovepipe Applications

Today’s Architecture

DataWarehouse

LegacyMainframes

Web Servers

ApplicationServers

ApplicationServers

Workstation

ReportServer

DataMarts

DataMarts

Data

Data

Data

Technologies Used for Integration

Message Oriented MiddlewareMOM

(Hub and Spoke)

Data Warehousing

Marts

MartsMarts

Marts

Warehouse

Web Services

Service LegacyXML

Remote Method InvocationsRMI

Object

Object

Roadmap to SOA

Start by creating services around existing processes within applications

Application

BusinessProcess

BusinessProcess

BusinessProcess

ServiceServiceService

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)

XMLXMLXML

Roadmap to SOA

Moving from Stovepipes . . .Moving from Stovepipes . . .

Service

XML

Application

BusinessProcess

Service

XML

Service

XML

Service

XML

Service

XML

BusinessProcess

Application

BusinessProcess

BusinessProcess

BusinessProcess

Application

BusinessProcess

BusinessProcess

BusinessProcess

ServiceService

XMLXML

Service

XML

Roadmap to SOA

Moving from Stovepipes . . . To Shared ServicesMoving from Stovepipes . . . To Shared Services

Application

BusinessProcess

BusinessProcess

BusinessProcess

ServiceServiceServiceService

Application

BusinessProcess

ServiceServiceServiceService

BusinessProcess

Application

BusinessProcess

BusinessProcess

BusinessProcess

Transformation

XML XML XML

Transformation

XML XML XML

Transformation

XML XML XML

Enterprise Interoperability HubEnterprise Interoperability Hub

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.

External AgencyService

SOAP Service

Portal Service

New ApplicationService

MOM Service

Data Service

RequestRequestTransformation/Routing ServicesTransformation/Routing Services

Orchestrated Transactionsand Event Driven ServicesOrchestrated Transactionsand Event Driven Services

Enterprise Interoperability HubEnterprise Interoperability Hub

Roadmap to SOA

Today’s Architecture

DataWarehouse

LegacyMainframes

Web Servers

ApplicationServers

ApplicationServers

Workstation

ReportServer

DataMarts

DataMarts

Data

Data

Data

Future Architecture

Roadmap to SOA

LegacyMainframes

Web Servers

ReportServer

EnterpriseInteroperability

Hub(Service Bus)

EnterpriseInteroperability

Hub(Service Bus)Workstation Application

Servers

ApplicationServers

Data

Data

Data

DataMarts

DataMarts

DataWarehouse

Exposed Service

Exposed Service

Exposed Service

Exposed Service

Exposed Service

Future Architecture

Roadmap to SOA

LegacyMainframes

Web Servers

ReportServer

EnterpriseInteroperability

Hub(Service Bus)

EnterpriseInteroperability

Hub(Service Bus)Workstation Application

Servers

ApplicationServers

Data

Data

Data

DataMarts

DataMarts

DataWarehouse

Exposed Service

Exposed Service

Exposed Service

Exposed Service

Exposed Service

Jeff Simpson

SOA Best PracticesSOA 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

LegacyService A

LegacyService B

LegacyService C

RationalizedService

router

adaptor adaptor adaptor

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

WebService Enabled

PeopleSoft

Integrating the Integration

WebService Enabled

SOA FabricSOA Fabric

Process / Data IntegrationApp ServerApp Server

WebService Enabled WebService Enabled

HR System 1 HR System 2 HR System 3

Broker (BEA, WebMethods or Tibco)

WebService Enabled

Broker

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.