Transcript The Future of Web Services

Connected Applications and
Indigo
Felipe Cabrera
Architect
Microsoft
1
Agenda
Recap of service-orientation trend
Web Services Architecture
Indigo
Prescriptive guidance
Q&A and Feedback
2
IT as Business Value Driver
Old IT
Functional islands
Built to spec
Constrains business
IT-business “alignment”
IT accountable
Cost driver
Technology adjunct
New IT
Everything connected
Built for change
Empowers business
IT and business are one
Joint accountability
Value driver
Business platform
Representing Data
Today
Non-standard data representations
Mostly human “Trim-and-Shim” to integrate
Beginnings of standardization
Web services foundation
Need industry standards
Demand for business process
Going forward
Industry de facto standards
Increased compatibility
More sophisticated business process
The Evolution to Services
2000+
Web Services
Service-Oriented
Solutions
Late 1990s
Web technologies appear
e.g. HTTP, HTML, XML
Early 1990s
Pre-1990s
Application integration
technologies appear
Custom, static
B2B Integration
Business Benefit
5
Toward Service-Oriented Solutions
Service-orientation is not new
Academic OS community has written about them at
least since the 70s
Messaging has been broadly enabled since BSD 4.2
Has been practiced in large enterprises for many years
On a wide range of hardware/software platforms
Important Complement to Object-Orientation
Learns from Components, Distributed Objects, and
Message-Oriented-Middleware
Service-orientation has had false starts
CORBA
RMI
DCOM
…
6
Service-Oriented Architecture
Boundaries are explicit
Services are autonomous
Services share schema and contract
Not class
Services establish explicit relationships
Service compatibility is based on policy
New Success Factors
Better economics
Hardware advances make XML processing possible
Adopting the Internet model
Autonomy is central to success
Heterogeneity is a given
Enabling real interoperability
More principled architectural approach
Secure, reliable, transacted, asynchronous messaging
Use of metadata
Policies to express capabilities and requirements
Tools
Design, develop, debug, deploy
8
Microsoft Activities
Microsoft is working in different fronts to make
service-orientation ubiquitous
SOAP, WSDL, UDDI, HTTP, XML
.NET (2000)
Web Service Architecture based on a WS-* family of
specifications (2001 - 2004)
Web Service Enhancements (WSE) (2003)
WSE V2 (2004)
Indigo Beta (2004)
9
Agenda
Recap of service-orientation trend
Web Services Architecture
Indigo
Prescriptive guidance
Q&A and Feedback
10
Design Principles
Modular and composable
Factored to stand alone or work together
General-purpose
Agnostic to place it is running or originated
Standards-based
Multi-vendor interoperation is critical
Federated
No central point of administration, control, failure
11
Architecture Approach
Single universal model for all interactions
Scale (process, machine, cluster, Intranet, Internet)
Node types (clients, servers, devices)
Trust boundaries (may be mutually suspicious)
Execution instances (asynchronous)
Versioning and deployments (loosely coupled)
Implementation stacks (OS, language, …)
Must
Provide interoperability
Achieve wide adoption
12
A Universal Architecture for
Web Services
Security
Reliable Messaging
“Scales Up”
Transactions
on large
Routing
systems
…
“Scales In”
on a machine
“Scales Down”
to devices
“Scales Away”
spans organizations
& geographies
“Scales Out”
by adding
machines
Messaging Infrastructure
Distributed applications
Vertical processes
Embedded systems
Network equipment
…
13
WS Architecture Evolution
Secure, Reliable, Transacted
Jan/Feb 2004
WS-Eventing
WS-BusinessActivity
WS-Discovery
July 2003
WS-Federation
March 2003
WS-ReliableMessaging
WS-Addressing
RM Roadmap
April 2002
WS-Security and
Security Roadmap
SOAP
UDDI
March 2004
WS-MetadataExchange
September 2003
WS-AtomicTransaction
WS-Coordination
December 2002
SRT WS Whitepaper
WS-Policy
WS-Trust
WS-SecureConversation
WS-I
2000
August 2002
WSDL
WS-Transaction
WS-Coordination
Web Services Specifications
Development Process
Specification
Published
Feedback and
Interop
Workshops
Revise
Specification
Participation
Standards Org
WS-I
Feedback Workshops:
Are open to everyone
Need to sign workshop feedback agreement
Goals:
Get feedback on technology
Our experience is that they:
Yield well-engineered technology
Provide fastest time to market
Specification is revised based on feedback
Feedback
Workshops
March 2004
WS-Transaction
February 2004
WS-Eventing
July 2003
WS-ReliableMessaging
February 2003
WS-Policy and
WS-Trust
2002
November 2003
WS-Federation
March 2003
WS-Policy and
WS-Trust
Q2 2004
WS-SecureConversation
WS-Trust
WS-Federation
WS-Discovery
Interoperability Workshops:
Open to teams with implementations
Goal:
Demonstrate interoperability
Our experience is that they:
Help refine the important scenarios
Ground the development efforts
Specification revised based on interoperability
feedback
Interoperability Events
& Workshops
September 2003
Bill Gates (Microsoft)
Steve Mills (IBM)
Nov 2003
WS-Trust
WS-SecureConversation
(workshop)
March 2004
SOAP December 2002
WS-Federation Passive
Builders CDBi - EMEA
Profile (workshop)
October 2003
2002
WS-ReliableMessaging
(workshop)
Q2 2004
WS-SecureConversation
July 2003
WS-Trust
September 2003
Catalyst
WS-ReliableMessaging
OASIS
(Burton conference)
WS-Policy
WS-Security
WS-AtomicTransaction
August 2002
WS-BusinessActivity
XML Web Services
Q3 2004
One (East)
WS-Discovery
Agenda
Recap of service-orientation trend
Web Services Architecture
Indigo
Prescriptive guidance
Q&A and Feedback
20
What Is Indigo?
A set of Windows features for building and running
service-oriented applications in managed code
Available in Longhorn timeframe
Available for Longhorn, Windows XP,
Windows Server 2003
A unified programming model and runtime
Across Microsoft’s existing distributed technologies
Across hosting models
Across node types
Across different levels of scale
Longhorn Architecture
22
Indigo (1/2)
Provides the interconnection fabric
Supports fine-grain composition of features
It is a platform with architected extensibility
Separates development of core functionality
and deployment considerations
Like durability, or service topology
Exploits SOAP for transport independence
Includes the ability to transfer metadata
23
Indigo (2/2)
Enables pervasive transactional behavior
with a light-weight transaction manager
Deploys reliable-messaging in the low-end
Has a light-weight publish/subscribe
infrastructure that is extensible
Topic management is layered
Provides a powerful “filter engine” to enable
content-based message dispatch
24
IOutputChannel
Port
+ChannelProviders
+PortExtensions
+Services
+CreateChannel( )
+CreateListenerChannel( )
«signal»+ListenerChannelNotFound()
+Send(in msg : Message)
+BeginSend()
+EndSend()
IDuplexChannel
IInputChannel
+Receive() : Message
+BeginReceive()
+EndReceive()
«signal»+MessageAvailable ()
IChannel
IReplyChannel
IRequestChannel
+IsOnline : bool
+IsOpen : bool
+Capabilities
+Open()
+Close()
«signal»-Closed()
«signal»-Offline()
«signal»-Online()
+Request(in msg : Message) : Message
+BeginRequest()
+EndRequest()
+Receive() : Message
+Send(in msg : Message)
+BeginReceive()
+EndReceive()
+BeginSend()
+EndSend()
«signal»+MessageAvailable ()
Message
MessageHeader
+Body : XmlReader
+Headers : MessageHeader
+Close()
+Clone()
+ReadXml(in reader : XmlReader)
+WriteXml(in writer : XmlWriter)
+SetProperty(in name : string, in value : object)
+GetProperty(in name : string) : object
+Namespace : Uri
+Name : string
+MustUnderstand : bool
+Relay : bool
+Role : Uri
+WriteXml(in writer : XmlWriter)
+ReadXml(in reader : XmlReader)
25
[Confidentiality]
[Reliability(Guarantees.ExactlyOnce | Guarantees.InOrder)]
[Service]
class HelloService {
[TransactionCoupling(
TransactionCouplingOptions.Required)]
[ServiceMethod]
String Hello(String Greeting) {
return Greeting;
}
}
1 line
of security code
1 line of reliable
messaging code
1 line of
transaction code
Total count: 3
26
Agenda
Recap of service-orientation trend
Web Services Architecture
Indigo
Prescriptive guidance
Q&A and Feedback
27
Indigo And Unification
ASMX and WSE
Simple Config
Interoperable
Service-Oriented
.NET Remoting
Broad Vision
Extensibility
Object-Oriented
Enterprise Services
System.Messaging
Attributes
Transactions
Components
Queuing
Reliable Msg
Durable Msg
Indigo
Indigo is a superset of the capabilities of our existing stacks
Preparing For Migration:
Know Your Boundaries
Application boundaries
Platform
Deployment
Trust
Across boundaries use services
Within a boundary both services and
objects are appropriate
Today’s Prescriptive Guidance
Build services using ASMX
Enhance your ASMX service with WSE if you need the WSE
feature set and you can accept the support policy
Use object technology in a service’s implementation
Use Enterprise Services if
You need ES rich feature set
You are communicating between components on the local
machine and have performance issues with ASMX or WSE
Use .NET Remoting if
You need to integrate with an existing proprietary protocol
You are communicating in-process, cross app domain
Use System.Messaging if you need the reliable
messaging and queuing features in MSMQ
30
Today’s Caveats
ASMX
Avoid or abstract using low-level extensibility such as the HTTP Context
object
.NET Remoting
Avoid or abstract using low-level extensibility such as .NET Remoting
sinks and channels
Enterprise Services
Avoid passing object references inside of ES
Do not use COM+ APIs – use System.EnterpriseServices
Do not use MSMQ APIs – use System.Messaging
31
The WSE Speedboat
If you can get value out of a jump-start use
Web Services Enhancements
PSS calls are supported
Has shorter life-span as product
Targeted to ‘Elvis’ and ‘Einstein’
32
Q&A
and
Feedback
When in doubt look in
http://msdn.microsoft.com/webservices
33
WSE v2.0: Enhanced Security
Trust Issuing Framework (WS-Trust)
Secure Conversation (WSSecureConversation)
Roles based authorization
Security Policy (WS-SecurityPolicy)
34
WSE v2.0: Policy Driven Architecture
Beyond WSDL, what else is needed to describe a
Web service?
Security requirements
Reliable messaging assurances
Protocol versioning
Etc…
These other attributes of a service can be
described with WS-Policy
XML-base language
Complex: <Or>, <ExactlyOne>, etc…
WSE provides a Policy Framework with send-side
and receive-side policy support
35
WSE v2.0: SOAP Messaging
WSE offers four classes for messaging
SoapSender and SoapReceiver
One way messages
Low-level
SoapClient and SoapService
One-way and two-way
Uses SoapSender/SoapReceiver
Offers XML serialization support
Operation dispatching
36
WSE v2.0: Multiple Hosting
Environments
Applications can be hosted in multiple
environments: ASP.NET, .exe, NT Service,
WinForms, etc.
Support for multiple transports
In-process communication
Raw TCP
HTTP
Asynchronous support
37