Title: Best Practices for Adopting SOA
1Best Practices for Adopting SOA
2SOA Overview
3What 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)
4What Has Slowed True SOA Implementations?
- Proprietary tools
- Lack of universally accepted protocols
- Enterprise governance less emphasized
- Legacy roadblocks
Result is StovePipe Integration
5What 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
6A 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
7Integration of Services
- The integration of services becomes the Service
Bus,or what we like to call the Interoperability
Hub
8Walk Then Run
- Start with simple document-oriented exchanges
- Enhance through service aggregation
- Prudently evolve toward document-oriented
Publish/Subscribe and Orchestrated relationships
9SOA 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.
10Troy Holmes
Implementing SOA
11How 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.
12How 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
13How 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.
14How 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
15How 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
16How Agencies are Integrating Stovepipe
Applications
LegacyMainframes
Todays Architecture
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
17Technologies Used for Integration
18Roadmap 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)
19Roadmap to SOA
Moving from Stovepipes . . .
20Roadmap to SOA
Enterprise Interoperability Hub
XML
XML
XML
XML
XML
XML
XML
XML
XML
Moving from Stovepipes . . . To Shared Services
21Roadmap 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
22Roadmap to SOA
LegacyMainframes
Todays Architecture
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
23Roadmap to SOA
LegacyMainframes
EnterpriseInteroperabilityHub(Service Bus)
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
24Roadmap to SOA
LegacyMainframes
EnterpriseInteroperabilityHub(Service Bus)
Workstation
ApplicationServers
ApplicationServers
Web Servers
ReportServer
25Jeff Simpson
SOA Best Practices
26What 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
27Implementation Best-Practices
- What is the Use-Case?
- Plan for reuse
- Transactions
- Tuning and Management
28Plan for Reuse
- Scalability
- Reliability
- Deployment
- Documentation
29Pick 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.)
30To 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
31WebService Management
- What does it provide?
- Quality of Service (QoS)
- Service Level Agreements (SLAs)
- Registry Services
- When to involve the technology?
32Rationalization 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?
33Service 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
34Portal Rationalization
- Collapsing the web interfaces from multiple
systems into a single portal by having each
interface be its own portlet within the portal
35Composite 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
36Integrating 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
37Adapting 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.