Moving to a Services Oriented Architecture: Strategies and Practical Approaches

1
Moving to a Services Oriented ArchitectureStrate
gies and Practical Approaches
2
Moving to a Services Oriented Architecture
Strategies and Practical Approaches
Tim Gruver (tgruver_at_microsoft.com) Architect Nati
onal Architecture Team Microsoft Corporation
3
Agenda

• What is SOA?
• Why SOA?
• How do I think about designing a SOA?
• Design considerations
• Summary

4

• The major differentiator between companies now
  is their agility their ability to create value
  quicker than their competitors. This may be the
  only differentiator in the future, as every other
  innovation can be copied.
• -Rolf Jester
• Chief Analyst IT Services Market Asia/Pacific
• Gartner

5
Changing Architecture
From
To

• Tightly coupled
• Cost centric
• One platform
• Application centric
• Object oriented
• Know every detail
• More connections more costs

• Loosely coupled
• Value centric
• All platforms
• Actionable data
• Message oriented
• Abstraction
• More connections more value

6
From this..
Results
Billing
Revenue
Pharmacy
Oncology
EMPI
7
To this..

• Basic Services
• Service Business Process Orchestration

EMPI
8
A more complex view..
9
SOA Definition

• A service-oriented architecture is one where the
  application is cut into pieces called services
• Each service is invoked by messaging
• The semantics of the operations are around
  business functions

10
Microsofts Vision for SOA

• Service orientation will encapsulate and
  componentize processes and systems
• Business capabilities and business processes
  will be modeled as services

11
Three Reasons for Using Services

• Autonomy of Applications
• Independent Development and Evolution
• Clarifies Encapsulation and Privacy of Data
• Separation of Biz-Process and App
• Allow Separate Development of Biz-Process
• Apps Gravitate to Managing Resources
• Enabling IT Infrastructure
• Surround the App (Service) in Predictable Way
• Connect the App (Service) into IT Infrastructure

12
Three Categories of Service Use

• Building New Solutions With Services
• Independent Pieces Within Apps
• Independent Development and Maintenance
• Scale-Out
• Cleaving Apart Existing Apps
• Disentangling the Big Ball of Mud
• Cleaving Together Existing Apps
• Connectivity
• B2B Business-to-Business
• EAI Enterprise Application Integration
• Business Process
• Tap Into IT Infrastructure

13
Agenda

• What is SOA?
• Why SOA?
• How do I think about designing a SOA?
• Design considerations
• Summary

14
Services Communicate With Messages

• Services Communicate with Messages
• Nothing Else
• No Other Knowledge about Partner
• May Be Heterogeneous

15
Service-Requests and Services-Responses

• Messages arrive into a service to request
  operations
• These are called service-requests
• The service will send messages back in response
  to the incoming service-requests
• These are called service-responses
• The interaction with a service frequently takes
  this request-response pattern
• It may have a more flexible pattern

16
Messages Are Special

• Between Services is Special
• Messages Are Sent and Float Around Between
• Special Care Is Needed to Understand Them
• Can Be Confusion About Interpreting Them

No Mans Land!
17
Any Form of Messaging is OK

• Many Kinds of Messaging
• Email, IP, TCP/IP, HTTP, MSMQ, MQ-Series, and
  more
• Advantages and Disadvantages to Each
• HTTP is Ubiquitous (Huge Advantage)
• MQ-Series Lots of Platforms
• Email (Over SMTP) is Ubiquitous (Huge Advantage)
• Ubiquity Is Essential
• Connecting Within Your Enterprise
• Connecting With Your Partners

18
Composite Business-Services

• A Business-Service May Be Implemented by Many
  Business-Services
• Perhaps on Many Machines
• Essential for Scale-Out Solutions
• Must Look Like a Single Business-Service
• Cant Tell from the Outside

19
Agenda

• What is SOA?
• Why SOA?
• How do I think about designing a SOA?
• Design Considerations
• Summary

20
Design Considerations

• Things we should be thinking about
• Security
• Transactions and SOA
• What does it mean to think about transaction in
  an SOA world
• How do we delineate transaction boundaries
• What infrastructure support can we expect
• Idempotency of Services
• Reliability issues make us assert that services
  should be idempotent.
• Data fidelity between services
• Canonical Schema goals and challenges

21
Security and SOA

• Need not be part of message
• Leverage infrastructure services
• It means more than just authentication
• Authorization
• Encryption
• Digest
• Standards (WS-) are still evolving to date

22
Transactions and SOA Issues

• Atomic transaction are singularities
• Locking makes them appear to be at a single point
  in time
• Two-phase commit removes distribution concerns
• The new challenges happen when spreading work
  across space and time
• Different services are in different spatial
  locations
• Work across different messages gets processed at
  different times

23
Challenges with Multiple Messages

• Any request may arrive multiple times
• Sometimes after quite a while
• You might be a few messages farther along when an
  old one arrives
• The combinatoric complexity can be staggering
• This leads people to build very simple
  applications since only then can they cope with
  the failure complexity

Problem !!!
24
Building a Conversation for Multiple Messages

• Conversations Help with Correctness
• Can Ensure Automatic Idempotence
• Even When Changing Data
• Not for First Message in Conversation
• Correlate Messages and Data
• Connecting Them to Earlier Messages
• Allowing Data to Be Correlated
• Conversations Must Be Long-Running Durable
• They Live as Records in the Database
• Conversations Connect Business-Services
• Using the SQL Database as the Conversation
  Storage

25
Message processing infrastructure
Service
Log
Sign
Message Processing Infrastructure
Serialize
Monitoring
Service
Reliable messaging
Encrypt
Authorize
Eventing
Audit
Message Processing Infrastructure
Deserialize
Routing
Authenticate
26
Services in perspective
Service
Log
Sign
Message Processing Infrastructure
Serialize
Service
Reliable messaging
Encrypt
Authorize
Audit
Message Processing Infrastructure
Deserialize
Authenticate
27
In Summary

• Services Move Us Forward
• Lots of Islands of App Code
• Services Are for Connecting the Islands!
• Independence Is Essential
• Services Evolve Independently
• Build versus Buy
• Inside Your Company and Across Companies
• Connecting Your Disparate Apps Comes First!
• Hooking to Partners Is Important, Too!
• Its all about integration
• Services Cleave Your Applications
• They Cleave Them Apart Into Independent Pieces
• They Cleave Them Together Allowing Interaction
• Further Reference msdn.microsoft.com/architecture
  
• msdn.microsoft.com/practices

28
Thank you for attending. Visit www.mshug.org.