Post on 15-Jan-2017
So You Want an SOA: Best Practices for Migrating to SOA in the EnterpriseEric Newcomer, CTO
2
OverviewFirst of all: concepts and definitionsChange your thinking about your IT environmentIncluding organization and skill setEmbrace heterogeneity and complexitySupport businesses agility to:Reduce complexityImprove integration and data sharingBecome more competitiveMove toward services and SOA adoption:Map IT services to business servicesStart with incremental changeUnderstand and apply architectural best practices
3
Concepts and definitionsServices and SOA are technology independentThey represent “styles of design”Have been mapped successfully to CORBA, WebSphere MQ, Web servicesN-tier technologies are the best fitCORBA, Web servicesA service includes:A requesterA providerOne or more message exchange patterns
Requester Provider
UDDIRegistry
SOAP
WSDL
4
Concepts and definitions (cont)Services model human and business functionsNot software artifacts such as databases or filesUnlike objects, services are not “things”Services are defined by the messages they exchangeRequest list of customersUpdate the customer’s orderNotify the call center operatorTransfer my funds The design concept is the message schema
5
Credit Suisse: SOA pioneer
Enterprise Services
INFORMATION BUS
MS - COM COMet
MS - COM COMet
Service ContractService Contract
C++ CORBA(ORBIX 3)
C++ CORBA(ORBIX 3)
Service ContractService Contract Service ContractService Contract
Java CORBA(ORBIX 3)
Java CORBA(ORBIX 3)
Service ContractService Contract
Smalltalk-/SecureBrokerSmalltalk-/
SecureBroker
Service ContractService Contract
WebLogic-Orbix Java 3.3.1
WebLogic-Orbix Java 3.3.1
IIOP-----SSL
IIOP-----SSL
Mainframe PL1 Resources
Mainframe PL1 Resources
Service ContractService Contract
TivoliManagement
TivoliManagement
Service ContractService Contract Service ContractService Contract
HP OpenViewManagement
HP OpenViewManagement
Service ContractService Contract
MainframeCICS Resources
MainframeCICS Resources
Service ContractService Contract
Mainframe IMS ResourcesMainframe
IMS Resources
Enterprise Services
Enterprise ServicesEnterprise Services
INFORMATION BUS
MS - COM COMet
MS - COM COMet
Service ContractService Contract
C++ CORBA(ORBIX 3)
C++ CORBA(ORBIX 3)
Service ContractService Contract Service ContractService Contract
Java CORBA(ORBIX 3)
Java CORBA(ORBIX 3)
Service ContractService Contract
Smalltalk-/SecureBrokerSmalltalk-/
SecureBroker
Service ContractService Contract
WebLogic-Orbix Java 3.3.1
WebLogic-Orbix Java 3.3.1
MS - COM COMet
MS - COM COMet
Service ContractService Contract
C++ CORBA(ORBIX 3)
C++ CORBA(ORBIX 3)
Service ContractService Contract Service ContractService Contract
Java CORBA(ORBIX 3)
Java CORBA(ORBIX 3)
Service ContractService Contract
Smalltalk-/SecureBrokerSmalltalk-/
SecureBroker
Service ContractService Contract
WebLogic-Orbix Java 3.3.1
WebLogic-Orbix Java 3.3.1
IIOP-----SSL
IIOP-----SSL
Mainframe PL1 Resources
Mainframe PL1 Resources
Service ContractService Contract
TivoliManagement
TivoliManagement
Service ContractService Contract Service ContractService Contract
HP OpenViewManagement
HP OpenViewManagement
Service ContractService Contract
MainframeCICS Resources
MainframeCICS Resources
Service ContractService Contract
Mainframe IMS ResourcesMainframe
IMS Resources
Enterprise Services
6
Services change the organizationA service architect determinesThe overall plan and design for servicesWhich services fit the model, which don’tDesign principles for services, especially reuseDevelopers update their skillsLearn to develop for future reuseWork with multiple technologies (Web services plus an execution environment – J2EE, CORBA, .NET)Business analysts may compose servicesGiven right levels of abstraction and toolset
7
Services embrace heterogeneityHeterogeneity and complexity are constantServices can abstract across any software systemApply “veneer” using XML and Web servicesExtend for enterprise qualities of serviceUnique characteristics are valuableMake complexity work for youJ2EE, .NET, CORBA, and Mainframe all have benefitExisting applications have functions with valueModernize without the expense of replacementMaintain enterprise QoS – reliability, transactions, security
8
Typical IT complexity map
Source: Deutsche Post World Net, SAP SI
9
• A “plug and play” view of IT architecture and systems
• Native interoperability and integration capabilities now available for every system end-point via a standards-base service interface
• Orchestration of core business processes, independent of underlying systems and adaptable to changing business conditions
• Investments in standards to help drive down long term operating costs and as a mechanism for insuring future interoperability between infrastructure and systems
• A “plug and play” view of IT architecture and systems
• Native interoperability and integration capabilities now available for every system end-point via a standards-base service interface
• Orchestration of core business processes, independent of underlying systems and adaptable to changing business conditions
• Investments in standards to help drive down long term operating costs and as a mechanism for insuring future interoperability between infrastructure and systems
Desired goal
SOP (Service Oriented Platform)
Business ProcessArchitecture
IT ApplicationLandscape
SOP (Service Oriented Platform)SOP (Service Oriented Platform)
Business ProcessArchitecture
IT ApplicationLandscape
10
Bank Teller analogy
Different types of tellers offer different servicesTellers specialized to perform certain types of transactions:
Account Management (Opening and closing accounts)Credits (inquiries, consulting, applying for mortgages)Cash Register (Withdrawals, deposits, funds transfers)Currency exchange (buy and sell foreign currencies)
Several tellers may offer the same set of services (for load balancing / failover)What happens behind the counter is not your business (but the IT systems need to support the tellers)If you require a complex transaction, you may have to visit several tellers (customer as transaction coordinator)
11
Move from monolithic applications in stepsIntermediate stage:
Break out individual services
Application
Application
service
service
Application
Application
service
Goal: Service-oriented architecture
service
service
service
service
Application
Monolithic applications
Application
12
Reasons to develop servicesNot for the sake of the individual applicationsServices don’t make sense in a mono-technology environmentFocus on reusability, component design, data sharingFor the sake of the next level developersOffice workers, business analystsCan share data without worrying about details of underlying implementationLay the foundation for future applicationsInfrastructure investment in “agility”
13
Service Contracts Are the Key
The key principles of service-oriented architecture (SOA)Services should be business-orientedServices should have well-defined interfaces (aka service contracts)Service contracts should separate interface from implementation Service contracts are critical to achieve reuse and abstraction
14
WSDL is best for service contractsWSDL is very flexible:
Import existing WSDL contractsCreate new WSDL contracts using
XML SchemaCreate new WSDL contracts from an
external metadata source such as CORBA IDL
Annotate with policy metadata
BenefitsAbstractionEncapsulationLoose-CouplingSeparation of Concerns
Service
Port
Binding
XML Data Type
Part
Message
Operation
PortType
WSDL
LogicalContract
PhysicalContract
•Logical Contract is what other applications care about• Physical Contract is extensible to support any middleware binding• XML Schema provides independent type system
15
An important question: How to decompose services?
Quality criteria used to measure the result:
1. Derived from top rank use cases (adequateness)2. Balanced with existing assets: platform technology,frameworks, components3. Balanced with requirements (trade-offs, performance vs. security,…)4. Compliance with (domain-specific) industry standards andreference models (interoperability, readiness for merging)5. Designed to make the system more resilient to futurechanges (20 years?) (maintainability)6. Designed for substantial reuse, and with substantial reuse7. Intuitively understandable (people buy-in!) (usability)
16
Considerations for SOA design
FunctionalitySoftwareArchitecture
Fault Tolerance
PerformanceCostThroughput
Capacity
Availability
Interoperability Fail safe
Maintainability
Scalability
17
Take the example of the Web
Human to computer interactions resolvedStandards in place for programming (HTML) and interoperability (HTTP)Huge value adds Highly productive, low cost Standardization at the network endpoints
18
Web Services: Composites for IT
Standards (WSDL & SOAP) and approach (SOA) need to be deployed – at the endpointsOpen source will help drive adoptionJoin Web 2.0 mashupsto enterprise dataCICS IMS
C, C++, COBOL, PL/I, Java, C#
19
PackagedApplications
Message Queuing/EAI
.NET, Java, Application
Servers
Databases and Files
WSDL
Leverage the power of the endpoints
WSDL WSDL WSDLSOAP SOAP SOAP
WebServices
layer
Add servicesto the endpoints
to standardize them
Applications have a common interface/protocol for composites
Platform/Legacylayer
Legacy Legacy Legacy
20
SecurityService
RetailerService
Credit CardService
Billing & Accounting
Service
OrderService
Result – Order Entry/Service Delivery
Telephone/Mobile Access
PC Access
DeliveryService
Satellite TV
Voice over IP
TV over IP
Services can be anywhere on the network, running on any platform, hosted by anyone
21
SummaryEnterprises want business agilityThey become agile by investing in servicesKey benefits include:Rapid application integrationMulti-channel accessObtaining service functionality over the InternetCreating new business models
SOA requires a change in thinking and organizationThe agile business embraces heterogeneity Resolving differences via services and SOABest practices involve considering many capabilities