Best Practices for Adopting SOA

1
Best Practices for Adopting SOA

• Bill McElhaneyTroy HolmesJeff Simpson

September 21, 2004
2
Bill McElhaney
SOA Overview
3
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)
4
What Has Slowed True SOA Implementations?

• Proprietary tools
• Lack of universally accepted protocols
• Enterprise governance less emphasized
• Legacy roadblocks

Result is StovePipe Integration
5
What is Different Now?

• Numerous tools and open standardsInternet, 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

6
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

7
Integration of Services

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

8
Walk Then Run

• Start with simple document-oriented exchanges

• Enhance through service aggregation

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

9
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.

10
Troy Holmes
Implementing SOA
11
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.

12
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

13
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.

14
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
GenericService
Consumer
Producer
API
API
Business Tier
Data Access Tier
Data Access Tier
15
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

Message
Contract
16
How Agencies are Integrating Stovepipe
Applications
LegacyMainframes
Todays Architecture
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
17
Technologies Used for Integration
18
Roadmap to SOA

• Start by creating services around existing
  processes within applications

• 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)

19
Roadmap to SOA
Moving from Stovepipes . . .
20
Roadmap to SOA
Enterprise Interoperability Hub
XML
XML
XML
XML
XML
XML
XML
XML
XML
Moving from Stovepipes . . . To Shared Services
21
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.

Enterprise Interoperability Hub
22
Roadmap to SOA
LegacyMainframes
Todays Architecture
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
23
Roadmap to SOA
LegacyMainframes
EnterpriseInteroperabilityHub(Service Bus)
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
24
Roadmap to SOA
LegacyMainframes
EnterpriseInteroperabilityHub(Service Bus)
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
25
Jeff Simpson
SOA Best Practices
26
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

27
Implementation Best-Practices

• What is the Use-Case?
• Plan for reuse
• Transactions
• Tuning and Management

28
Plan for Reuse

• Scalability
• Reliability
• Deployment
• Documentation

29
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.)

30
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
31
WebService Management

• What does it provide?
• Quality of Service (QoS)
• Service Level Agreements (SLAs)
• Registry Services
• When to involve the technology?

32
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?

33
Service Rationalization

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

Rationalized Service
router
adaptor
adaptor
adaptor
Legacy Service A
Legacy Service B
Legacy Service C
34
Portal Rationalization

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

35
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

36
Integrating the Integration
WebService Enabled
Broker (BEA, WebMethods or Tibco)
Broker
WebService Enabled
PeopleSoft
WebService Enabled
WebService Enabled
WebService Enabled
HR System 1
HR System 2
HR System 3
37
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.