1. Best Practices for Adopting SOA

2. SOA Overview

3. Service Oriented Architecture
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, it’s 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
Application
Application
Application
Application
Application
Application

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

6. Enterprise Governance being the objective:
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
Application
Business Rules
Data Transformation Rules
Application
Publish
Inquire
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
Business Function/Service Aggregation
Transformation/Routing Services
Orchestrated Transactions and Event Driven Services

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.
Application
Business Rules
Data Transformation Rules
Publish
Inquire

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.
Business
Tier
Consumer
Producer
Data Access
Database
API

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
Consumer
Generic Service
Producer
API
API
Data Access
Tier
Business
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
Secure Business Applications
Business Application
Service
Business Logic
Interface Facade
Producer
XML
Customizable Presentation Tier
Consumer ?
Message
Contract

16. How Agencies are Integrating Stovepipe Applications
Legacy Mainframes
Today’s Architecture
Data
Data
Workstation
Application Servers
Application Servers
Data
Web Servers
Data Warehouse
Data Marts
Report Server
Data Marts

17. Technologies Used for Integration
Message Oriented Middleware MOM (Hub and Spoke)
Data Warehousing
Marts
Warehouse
Remote Method Invocations RMI
Object
Web Services
Service
Legacy
XML

18. Roadmap to SOA
Start by creating services around existing processes within applications
Application
Business Process
Define current business processes within existing applications
Create course grain services that satisfy particular business processes
Service
Make these services available to the internal agency
XML
Expose these services to external agencies via an Enterprise Interoperability Hub (Service Bus)

19. Roadmap to SOA Moving from Stovepipes . . . Service XML
Business Process
Application
Service
XML
Application
Business Process
Application
Business Process
Service
XML
Moving from Stovepipes . . .

20. Enterprise Interoperability Hub
Roadmap to SOA
Application
Application
Application
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Service
Service
Service
Service
Service
Service
Service
Service
Enterprise Interoperability Hub
Transformation
Transformation
Transformation
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.
SOAP Service
External Agency Service
Portal Service
Enterprise Interoperability Hub
Request
New Application Service
Transformation/Routing Services
Orchestrated Transactions and Event Driven Services
Data Service
MOM Service

22. Roadmap to SOA Today’s Architecture Legacy Mainframes Workstation
Data
Data
Workstation
Application Servers
Application Servers
Data
Web Servers
Data Warehouse
Data Marts
Report Server
Data Marts

23. Enterprise Interoperability Hub (Service Bus)
Roadmap to SOA
Data
Data Marts
Data Warehouse
Exposed Service
Future Architecture
Legacy Mainframes
Enterprise Interoperability Hub (Service Bus)
Workstation
Application Servers
Application Servers
Web Servers
Report Server

24. Enterprise Interoperability Hub (Service Bus)
Roadmap to SOA
Data
Data Marts
Data Warehouse
Exposed Service
Future Architecture
Legacy Mainframes
Enterprise Interoperability Hub (Service Bus)
Workstation
Application Servers
Application Servers
Web Servers
Report Server

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? UDDI.org
The defacto standard –
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
Service Fabric
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
Process / Data Integration
App Server
Here is the initial state: Three HR Systems that are web service enabled and then included in the SOA Fabric.
But … these HR systems are aging and the system requirements are ageing … their days are numbered. In order to get the required functionality, management has selected PeopleSoft as the target platform.
As a Pilot only HR System 3 will be integrated into the PeopleSoft system. This integration will be done as a function of migrating to the PeopleSoft system.
SOA Fabric
WebService Enabled
Broker
Broker (BEA, WebMethods or Tibco)
WebService Enabled
WebService Enabled
WebService Enabled
PeopleSoft
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.