Connected Systems and Service Oriented
Architecture
Francesco Albano
Enterprise Technical Evangelism Manager
Developer & Platform Evangelism Division
Microsoft Italy
Agenda
Service Orientation
Web Services Architecture
Technology Roadmap
2
Sound Familiar?
“… I need to bring 50 new services
to market in next 12-18 months”
APPLICATIONS AND SERVICES
“… I need to be driving $X00 million
in revenue from new services in the
next two years”
“… it costs me $2 million to launch
each service”
“…It takes too much time and
energy to bring even a simple
service to life”
NETWORK AND BACK-END ELEMENTS
Current infrastructure does not
have the agility to keep up with
business objectives
3
What Is SOA? – Concepts
Systems built from autonomous services
A service is a program you interact with via
message exchanges
Services are built to last
Availability and stability are critical
A set of deployed services is a system
An SOA is an orchestrated sequence of messaging,
transformation, routing and processing events in
which XML technologies expose the message
content and the components that operate on
the messages.
4
Services  Objects
Different deployment model
Services are hosted, rather than forward-deployed
Encapsulation at the interface, rather than the
implementation
Opportunity for interception and pipeline processing
Opportunity for context- and content-sensitive routing
Integration by Design
All platforms can consume contracts and messages
Opportunity to develop common entity model with
marketplace partners
5
Baseline Standards – Web Services 1.0
Web Services are here today!
Web services core:
XML 1.0 (second edition)
Base encoding for documents
SOAP 1.1
Base encoding for messages
WSDL 1.1
Description of web services
UDDI 2.0 (API 2.04, data structure 2.03)
Directory for finding service descriptions
HTTP 1.1
Message transfer
8
Great Baseline Specification But…
Solutions have become more complex and need standards
beyond this baseline
Need higher lever functionality to support Enterprise
Applications
Security – Authentication and Authorization
Routing
Reliable Messaging
Transactions
Today these types of services can be implemented however
they are usually some-what proprietary and often noninteroperable…
9
Shift To Service Orientation
From
To
Connections = cost
Function oriented
Build to last
Prolonged development
Connections = value
Process oriented
Build for change
Incrementally deployed
Application silos
Tightly coupled
Object oriented
Orchestrated solutions
Loosely coupled
Message oriented
Service Orientation
A service oriented architecture (SOA)
significantly elevates the abstraction level
for code re-use
It allows applications to bind to services
that evolve and improve over time without
requiring modification to the applications that
consume them
Evolution not revolution
11
Service Orientation – Core Tenets
Explicit Boundaries
Autonomous
Negotiation Via Policy
Exposed Schema
and Contract
Message Driven
Reuse
& Dynamic
Meaningful
Information
12
Service Orientation – Key Concepts
Applications
Operational
Requirements
State
composed of
manage
enforce
Policies
have
governed by
Services
bound by
exchange
Message Exchange
Pattern
Contracts
describe
contain
Messages
is a set of
Schemas
define structure of
13
Service Orientation
Business Process View
Coarse
Grained Web
Service
Operations
Finer Grained
Internal
Service
Operations
Fine Grained
Object and
database calls
Business
Component
Business
Component
Consumer
Application
Business
Process
14
Service Orientation
Required Capabilities
Security
Reliability
Transactions
Discovery
Management
Transport independence
Interoperability
Process orchestration
15
SOA – Current Standards
Addressing these Application Interoperability areas
WS-* Specifications
Co-authored, (inc. MS, IBM, BEA, Verisign, SAP, Tibco)
WS-Routing
WS-Referral
WS-Inspection
WS-Security
WS-Attachments
WS-Coordination
WS-Transaction
WS-SecureConversation
WS-SecurityPolicy
WS-Policy
WS-PolicyAttachment
WS-PolicyAssertions
WS-Addressing
WS-ReliableMessaging
16
Unified Connectivity
Less overhead, reduced surface area
Consistent programming model
Native interoperability
EJB
MQ
DCOM
Your
Application
ODBC
17
Abstraction
Enables you to more gracefully
decompose your application
Enables you to extend and optimize
your processes
Business
Processes
Your
Application
Business
Process
Business
Processes
18
Dynamic
Discovery enables you to add services and
consume services at “run-time”
Policy enables services to dynamically
calibrate and optimize overtime
Guaranteed Delivery
PKI
Windows Credentials
Guaranteed Delivery
Windows Credentials
Custom Credentials
19
Resilient
Schema provides a mechanism to decouple
database, programming and “wire” format –
this makes your application more resilient to
change
Coarse grain messaging enables loose
coupling
Business
Process
<ORDER>…..</ORDER>
<ITEMS>…..</ITEMS>
1 Shoes 12.99
20
Reuse
Decomposition promotes reuse and enables more dynamic
business processes
Requires you to embrace a business process model
000197 TBLEDIT
SECTION.
000198******************************
000199*
000200 DISPLAY ROOM-TOTAL-NUM(TBL-IDX).
000201 DISPLAY TBL-IDX.
000202 MOVE ROOM-TOTAL-NUM(TBL-IDX) TO
WK-ALL.
000203 MOVE ROOM-RSV-NUM(TBL-IDX) TO
WK-RSV.
000204 PERFORM RITU-COMP.
000205 MOVE WK-ALL TO POW-0001.
000205 MOVE TBL-IDX TO POW-0002.
000205 MOVE 1 TO POW-0003.
000205 CALL "_XPOWTABLESETNUMERICTO"
USING BY VALUE ROOMTBL
000205 BY REFERENCE POW-0001 BY VALUE
POW-0002 POW-0003 .
3.3. Procurement
3.3.1 Sourcing and Supplier Contract Management
3.3.2 Purchasing
Request Resources
Manage
Requisition
Approva
Processl
Create
Purchase
Requisitions
Acquire/Purchase
Choose or
Default
Supplier for
Goods
Perform
Encumbrance
Check
Create
Auction Bids
Resources
Manage
Purchase
Item
Catalog
Manage
RFI/RFQ/
RFP
process
Verify/
Negotiate
Price
Purchase
Indirect
Materials
Purchase
Outside
Vendor
Services
Manage
Automatic
Replenishment
Manage
Purchasing
Methods
Consolidate
Approved
Requisitions
by Supplier
Purchase
Capital
Goods
Manage
Open to
Buy/Blanket
POs
Create
Purchase
Orders
Purchase
Direct
Materials &
Supplies
Track Open
POs
Approve
& Validate
Contract
Payments
Manage Suppliers
Manage
Supplier
Relationships
Track
Supplier
Commitments
Maintain
Supplier
Catalog
Manage
Buyer
Performance
Provide Supplier
Self-Help
3.3.3 Receiving of Indirect / Capital Goods and Services
21
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
Processes
 The end goal are declarative processes… how do we get
there?
22
Security and SOA
Need not be part of message
Part of an infrastructure service
It means more than just authentication
Authorization
Encryption
Standards (WS-*) are still evolving to date
23
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
Commutativity helps relax space and time
By reordering with acceptable answers, it’s OK
Note that DB write is not commutative
24
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
Challenges
with
Multiple
This leads
people to build very
simple
applications Messages
since only then
can they cope with the failure complexity…
Service-A
Sender
Service-B
C
B
A
C
A
B
Receiver
Problem !!!
25
Idempotence
Requests get lost…
Gotta retry them to handle lost requests
Requests arrive more than once…
Those pesky retries may actually arrive
Idempotent means it’s OK to arrive multiple times
As long as the request is processed at least once, the correct stuff
occurs
In today’s internet, you must design your requests to be idempotent
Naturally
Idempotent
Sweeping
the floor
Naturally
Idempotent
Read
Record X
Not Idempotent
Withdrawing
Idempotent
$1 Billion
Baking a cake starting
with a shopping list
(if you don’t worry
Not Idempotent
about money)
Baking a cake
starting from
ingredients
Idempotent
If not yet withdrawal
#XYZ then withdraw
$1 Billion and label
as #XYZ
26
Service-Oriented Analysis Issues
Entity Identification
Entity Factoring
Service Identification
Service Factoring
Process Specification
Endpoint (Touchpoint)
identification
Role Mapping
SLAs
…
Information
Architecture
Clients and Agents
Technology
Architecture
27
Service-Oriented Design Issues
Schema definition
Message definition
Contract definition
Message handling
Process
management
Transaction model
Operational
compliance
Exception handling
Message to Object
mapping
Refinement of
Analysis
…
Process
Service
Document
A
Document
C-1
Document
C-2
Contracts
Document
B
Either
C-1 or C-2
Service
Process
28
Service Operations Issues
Security
Access control
Monitoring
Management
QoS and SLA
enforcement
Versioning
Scalability
Dealing with
unreliability
Exception routing
Caching
Sign
Service
Log
Message Processing
Infrastructure
Encrypt
Authorize
Serialize
Reliable
messaging
Audit
Deserialize
Message Processing
Infrastructure
Authenticate
Service
29
Simplifying The Interaction Of Business Analysts And
Developers
Business analyst builds the
specific business process
bidirectional
collaborative
Developer ties processes in with
systems and other processes
30
One Developer Experience
Leverage existing skills
Harness the .NET framework
Build with standards
31
Business Rules/Policy
Use business process rules
for simple cases or
complete inference engine
for more complex scenarios
Rules change more often
than processes
Business rules provide
increased flexibility
Rules are abstracted from
process and user code
32
Building Connected Systems
Best Tool for Web Services Interoperability
Web
Services
Third party
Management
Products
LOB Apps
390/AS400
Windows
Clients
RDBMS
Other
Clients
LDAP
Mobile
Devices`
UNIX
VPN
Netware
Firewall
Identity
Management
Programming Language
Security
Data
Applications
Industries
Network
Legac
yInfrastructure
33
Visual Studio
Visual Studio
Visual Studio
Team Architect
Team Developer
Team Test
Application Designer
Dynamic Code Analyzer
Load Testing
Logical Infra. Designer
Static Code Analyzer
Manual Testing
Deployment Designer
Code Profiler
Test Case Management
Unit Testing
Code Coverage
Class Designer
Visio and UML Modeling
Team Foundation Client (includes CAL)
Visual Studio Professional Edition
Visual Studio
Team Foundation
Change Management
Reporting
Integration Services
Big Build
Work Item Tracking
Project Site
Project Management
Visual Studio Industry Partners
Process and Architecture Guidance
Visual Studio Team System
34
Closing Comments
Service-orientation allows an organization to
get control of unmanageable IT assets
Once in control, you can
Optimize
Orchestrate
Open access points to processes
Create agility
Top down or bottom up, SOA is a path to
better alignment of business and technology
36
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.