Transcript Presentation title - The dot.NET# Forums

Introduction to SOA with an Eye Towards
Indigo
Sam Gentile
INETA Speaker
.NET Consultant – Adesso Systems
Who is this Guy?
• Internationally known .NET guy




Working with CLR since 1999!
INETA Speaker, MVP – .NET/C#
Chief .NET Architect, Adesso Systems
.NET products and expertise for Microsoft, Groove (5
million lines of COM Interop), NaviSite, BCGI, Pacific
MindWorks
 Designed and implemented Groove Toolkit for Microsoft
Visual Studio .NET (JOLT Winner)
• Speaker for VSLive!, DevTeach, etc.
•
•
MSDN Columnist “Beyond Add Reference”, “Using
the .NET Framework SDK Interop Tools”
Major .NET/CLR Blogger (“Heart and Soul of .NET
Community”) at http://samgentile.com/blog/
 .NET Portal at http://samgentile.com/
It’s A User Group Thing
• As an INETA member, your User Group gets:




Visits from Speaker Bureau members at no charge
INETA even pays for the pizza
Discounts on software, conferences, subscriptions and more
Newsletter, content repository and forums of use to User Group
members
• INETA needs volunteers
 Benefit your User Group and yourself by getting involved
• INETA Web Site:
www.ineta.org
Agenda
• SOA for Dummies
• Introduction to WSE3
• WS-Security, WS-Secure Conversation with
WSE3
• Dive Into Indigo
SOA Hot on the Blogs
•
•
•
•
•
•
“Nothing new..” – Rocky Lohkta
“SOA Doesn’t Really Exist, Does It?” - Clemens
“Yes Clemens, there is Service Oriented Architecture” – JC Johnson
Rich Turner and Sam Gentile seem to be squarely in "let's drop the A in SOA"
camp.
“SO much to do w/ [insert technology of choice here] as OO had to do with C++,
Smalltalk, etc. Notions of SO are, if properly defined, pure, clean, abstract
and generally applicable to any given distributed systems platform.” RichTurner
Let’s dispense with 2 silly arguments straight away
 SOA is bogus because there's a lot of hype around it
 SOA is bogus because it's nothing new
• I contend, a real and excellent way to build loosely coupled,
distributed systems
 Also evolution of what we learned from OO, Components, etc
The Driving Forces
• The Internet and desire to go through firewalls
• COM/DCOM, CORBA, RMI all problematic
 All depend on binary reuse
• Business Process Optimization and “virtual enterprises”
• Heterogeneous systems are the reality
 People want a solution not based on platform, object model
• XML/SOAP is the only thing everyone can agree on
 COM, CORBA, RMI assume platform and model
• Reuse not at component level but across organization &
trust boundaries
Ideas Are Not New
• Ideas in Service Orientation and SOA have been around for
20 years
 We’ve been building distributed systems providing/consuming “services”
since 1980’s
• Examples are COM & CORBA with IDL




Separate interface from implementation is the key
Only way to access component was through interface
Service provided by client or component
IDL described service interface or contract separate from
implementation language
• What is different is clear focus on services as
DISTINCT from objects
An Early “Service”
[object, uuid(….)]
interface ICalculator : IUnknown
{
HRESULT Add( [in] long num, [out, retval]
long* answer);
HRESULT Subtract(…);
}
The Road to SOA
• DCE RPC in the 1980’s
• Object Orientation
 OO Reuse has largely failed
• CORBA, COM/DCOM, MTS/COM+
• Java, J2EE, RMI
• Component Oriented
 .NET first large-scale CO system with C# first “CO” language
• .NET
Service-Orientation in Context
Encapsulation
Polymorphism
Object-Orientation
Runtime Metadata
Explicit Contracts
Components
Service-Orientation
Flowable Context
Broker-based Binding
Distributed Objects
Queues & Relays
Explicit Message Passing
Message-Oriented
Middleware
What is a Service?
• Think about travel agency, utility company, ISP, etc





Publicized package of functionality
Composable (Travel agency makes use of transportation)
Discoverable on descriptions, terms & conditions
Use based on agreed-upon contract
Quality of service
• Software services not just described by contract but by
business terms
• Software Service characteristics




Available at particular endpoint
Receives/sends messages & behavior
Contract governs behavior
Quality requirements via policy
What is Service Oriented Architecture?
• Current buzzword of choice
 Hyped to the max!!
 Everyone has a (different) definition!
• Specific architectural style concerned with loose coupling &
dynamic binding between services
• Build applications made up of Composable Services
across separate domain boundaries made of
 Services only interact through messages
 Service Interfaces
 Service Implementation
• Three main entities:
 Service providers
 Service consumers
 Service directories
Service Orientation and SOA
• Simply, means for building distributed systems
• Architectural style not a framework (style of design)
 Web Services is a framework to build SOA applications
 Indigo is a framework and object model for SOA apps
• In SO, everything can be a service provider (in theory)
• Service providers expose capabilities through service
interfaces
• Fundamental: Separation between interface and
implementation
• Service Orientation allows you to create “Connected
Applications” (Microsoft term)
Four Tenants of SOA
• Boundaries Are Explicit
 Services only interact explicitly outside boundary via explicit message
passing
 Service agnostic to choices of platform, middleware or implementation
language
• Services Are Autonomous
 Independently functioning, deployed and versioned
• Services Share Schema & Contract, Not Class
 Interact solely on their expression of structures using schema and
behaviors via contracts
• Service Compatibility is Based On Policy
 Operational requirements, SLAs, policy assertions
Web Services and SOA
• Big Misconception: Web Services are for making RPC calls to
distributed objects using XML
• Reality: Web Services are not optimized for RPCs and work best when
they respond to messages
• We’ve been misled especially by VS.NET and ease of creating a ASMX
“Web Service” that is not a Service or SOA




VS.NET places method-centric focus on Web Services
Wrong design approach because WS then fails to provide a “service”
Messages are bound to rich and complex operations
RPC calls simply return discrete result directly correlated to specific set of input
parameters
• Right design approach is to always think in terms of messages and
operations in terms of a service
Web Services
• Services do things; perform a task and process well-defined XML
messages
• Services provide a well-defined interface that is described by XMLbased Web Service Description Language (WSDL contract)
• Services provide endpoints that Service Consumers and other
services can bind to based on service’s port address
• Services analogous to traditional OO, type-based components
 Defined interface and execute 1 or more methods
 Key difference is Service Consumers can flexibly bind to service
[These points reference “Expert Service-Oriented Architecture in C#”, Jeffrey Hassan,
pages 4-5]
Agenda
• SOA for Dummies
• Introduction to WSE3
• WS-Security, WS-Secure Conversation with
WSE3
• Dive Into Indigo
WS-Security,
WS-Trust,
WS-Secure Conversation
Reliable
Messaging
Transactions
WS-ReliableMessaging
WS-Transactions,
WS-Coordination
Messaging WS-Addressing …
XML, SOAP, XSD
Transports
HTTP, TCP, UDP, HTTPS, SMTP
WSDL, Policy
Security
Metadata
Web Services Spec Stack – WS-*
Goals of the WS-* Specs
• Composability




Fundamental to WS-Specifications
Most WS-Specs are independent of each other
Implement only the specs required
Building blocks in nearly any combination
• Interoperability
 Key goal of WS-Specifications
 Use only industry standard protocols such as WS-I Basic Profile (XML, SOAP,
WSDL)
• Message Orientation
 Use only messages to communicate between services
 Its All About Messages Baby!
The WS-* Specifications
• Autonomous Services
 Allowing endpoints to be independently built, versioned, managed,
deployed and secured
• Security
 SSL won’t cut it – only point to point (think intermediaries)
 WS-Security spec message-oriented security solution that supports
dynamic nature of messages
 Security info in header goes with message even if routed
 Additional specs to enforce security policies
• Description and Discovery
 Service could be accessed from different clients across different domains
The WS-* Specifications
 WSDL publishes supported types, operations and ports
 Ports specify abstract contract for types
 WSDL not sufficient to exchange all WS metadata
 WS-Policy provides general purpose model and syntax to communicate
policies to enforce for a service
• Messaging and Delivery
 WS-ReliableMessaging ensures reliable delivery of messages based on
specific delivery assurance characteristics
 Three Different Assurances:
 At-Least-Once Delivery
 At-Most-Once Delivery
 In-Order Delivery
WS-* Specifications Supported in WSE 2
Specification
WS-Security
XML namespace
http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-secext-1.0.xsd
WS-SecurityPolicy
WS-SecureConversation
http://schemas.xmlsoap.org/ws/2002/12/secex
t
http://schemas.xmlsoap.org/ws/2004/04/sc
WS-Trust
http://schemas.xmlsoap.org/ws/2004/04/trust
WS-Referral
http://schemas.xmlsoap.org/ws/2001/10/referr
al
http://schemas.xmlsoap.org/ws/2004/03/addre
ssing
http://schemas.xmlsoap.org/ws/2002/12/policy
WS-Addressing
WS-Policy
DIME
WS-Attachments
June 17, 2002 version
http://schemas.xmlsoap.org/ws/2002/06/dime/
soap
WS-* Specifications Supported in WSE 3
• SOAP Message Transmission Optimization Mechanism
(MTOM) for large amounts of binary data
• SOAP 1.2
• WS-SecurityAssertions (Turnkey Security Scenarios)
• Support for updated WS-Addressing, WS-Security, WSTrust and WS-SecureConversation
• User-defined policies in code
WSE = Web Service Enhancements
•
•
•
.NET class library for processing latest WS-Specifications
on top of ASP.NET/.NET
Allows add capabilities via code (design time) or policy file
(run-time)
Writing and Reading SOAP Headers
WSE as an SDK
• WSE is also an SDK that includes:
 Microsoft.Web.Services3 assembly
 API + support classes such as SOAP Extensions, handlers
 New WSE Settings 3.0 tool allows settings normally set in config or policy
file
 New VS2005 and .NET Framework 2.0 Support
 QuickStart samples
 X.509 Certificate Tool
 Policy Wizard
 Use this to generate XML policy expression files
 Documentation and Help Files
WSE Architecture
• Two sets of filters – inbound & outbound
• When message goes out, goes thru set of filters
that translate code into SOAP extensions applied
to message
• WSE is an extension to existing ASP.NET
processing pipeline
• WSE filters dedicated to groups of related specs:
 Security (including WS-Security)
 Policy (including WS-Policy and WS-Policy Attachments)
 Messaging (including WS-Addressing)
WSE Architecture
Picture from MSDN Help File
WSE Integration with ASP.NET
• WebServicesClientProtocol class exposes WSE input/output filters to
ASP.NET web service clients
 Extends base class for Web service proxies
System.Web.Services.SoapHttpClientProtocol
• Ensures WSE filters have chance to process SOAP message
• Have to change base class of your web service proxy to
WebServicesClientProtocol
 Easiest way to use WSE Settings tool
• WebServicesClientProtocol proxy base class implemented by two
communication classes:
 SoapWebRequest
 SoapWebResponse
WSE Integration with ASP.NET
• SoapWebRequest parses request stream with
SOAP message into instance of SoapEnvelope
class
• Key player in config with ASP.NET pipeline is
SoapContext class
 Records Web specification options and later makes them available
to WSE filters for processing
SoapContext requestContext = RequestSoapContext.Current;
• Refer again to picture
Configuring WSE 3
<configuration>
<configSections>
<section name="microsoft.web.services3"
type="Microsoft.Web.Services3.Configuration.WebServicesConfiguration,
Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</configSections>
<system.web>
<webServices>
<soapExtensionImporterTypes>
<add type="WseSettings.WseExtensionImporter, WseSettings3, Version=3.0.0.0,
Culture=neutral, PublicKeyToken=97707682dce9a66b" />
</soapExtensionImporterTypes>
</webServices>
<compilation>
<assemblies>
<add assembly="Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" />
</assemblies>
</compilation>
</system.web>
<microsoft.web.services3>
<diagnostics>
<trace enabled="true" input="InputTrace.webinfo" output="OutputTrace.webinfo" />
</diagnostics>
<tokenIssuer>
<statefulSecurityContextToken enabled="true" />
</tokenIssuer>
</microsoft.web.services3>
</configuration>
Installing X.509 Certificates
• Asymmetric Encryption (public key encryption)
• Three options:
 Use the WSE 2 test certificates (by far the easiest)
 Use the makecert.exe command line tool to make test certs
 Obtain a test certificate from Verisign
• Digital certificate and keys need to be in certificate
store
 Local Computer certificate store – Used by Web Service, store
public key
 Current User certificate store – Used by client, store certificate +
private key
Installing X.509 Certificates
1.
2.
3.
4.
5.
6.
Open new MMC console (mmc in Run dialog)
Select File | Add/Remove Snap-In and select Certificates. Select My User
Account and Finish
Repeat step 2 but choose Computer Account and Finish
Expand Personal folder of Computer User certificate store. Right-click All
Tasks | Import and import Private.fx
Right-click Personal folder of Current User and Import the sample test
certificate called Server Public.cer
Expand Personal folder of Local Computer certificate store and Import Server
Public.cer
These Instructions and Password are in the file
C:\Program Files\Microsoft
WSE\v3.0\Samples\Sample Test
Certificates\Readme.htm
And Now the X.509 Certificate Tool
Demo!
Adding WSE3 to a Web Service
Agenda
• SOA for Dummies
• Introduction to WSE3
• WS-Security, WS-Secure Conversation
with WSE3
• Dive Into Indigo
Review
• Authentication – validating who user is based on credentials or tokens
(username/Password or X.509)
• Authorization – based on user’s identity, what does he have access
to?
• Can use SSL to secure SOAP over HTTP but…
 SSL only designed for point-to-point communication
 Built on HTTP protocol
• SSL simply too limiting for Web Services security
• No new security mechanisms invented for SOAP-based messaging
 Kerberos tickets, public key encryption, X509 Certificates + others
WS-Security Stack
WS-Security
• Originally IBM/MSFT 2002; OASIS Standard in March of
2004
• Authentication
 Security credentials or tokens can be put in header
• Digital signing
 Sign SOAP message based on security token (UN/pwd or X.509 Certificate)
 Ensures message integrity
• Encryption
 Hashing SOAP message for message confidentiality
 Can encrypt SOAP message based on X.509 certificates
Digitally Signing a SOAP Message
• Cryptographic hash added to SOAP message based on
security token
• Several tokens supported:




Username-password (UsernameToken)
Digital certificate such as X.509
Kerberos token (Microsoft form)
Custom Binary token
Creating Username-Password Token
using Microsoft.Web.Services2.Security;
using Microsoft.Web.Services2.Security.Tokens;
using Microsoft.Web.Services2.Security.X509;
UsernameToken token;
string username = Environment.UserName;
byte[] passwordBytes = System.Text.Encoding.UTF8.GetBytes(
username);
Array.Reverse( passwordBytes );
string passwordEquivalent = Convert.ToBase64String(
passwordBytes );
token = new UsernameToken( username, passwordEquivalent,
PasswordOption.SendNone );
serviceProxy.RequestSoapContext.Security.Tokens.Add(token);
serviceProxy.RequestSoapContext.Security.Elements.Add( new
MessageSignature( token ) );
StockQuote[] quotes = serviceProxy.StockQuoteRequest(
symbols );
Creating X.509 Token
using Microsoft.Web.Services2.Security;
using Microsoft.Web.Services2.Security.Tokens;
using Microsoft.Web.Services2.Security.X509;
X509SecurityToken token = AppBase.GetClientToken( false );
X509SecurityToken token = null;
X509CertificateStore store =
X509CertificateStore.CurrentUserStore(X509CertificateStore.MyStore
);
X509CertificateCollection certs =
store.FindCertificateByKeyIdentifier( Convert.FromBase64String(
keyIdentifier ) );
if (certs.Count > 0) {
token = new X509SecurityToken( ((X509Certificate) certs[0]));
}
serviceProxy.RequestSoapContext.Security.Tokens.Add( token );
serviceProxy.RequestSoapContext.Security.Elements.Add( new
MessageSignature( token ) );
Modify Web Server To Process Signed SOAP
Messages
1. Loop through the collection of signatures attached to the
SOAP message
2. For each signature in the collection, determine what type
of token it’s based on
3. For username tokens, implement a custom token manager
to validate the token
We’ll look at this code in the demo
Demo!
WS-Security with Username Token
WS-Security with X.509 Token
WS-Policy and Use of Policies in Security
• Web Services cannot respond to any request that comes in!
 Your service may have some expectations or requirements for use
 Example: All incoming requests must be digitally signed and encrypted
• WS-Policy provides means to implement and enforce
standard policy framework for Web services
 General purpose model and syntax to describe & communicate the policies
of a web service
 Simple and extensible grammar for expressing policy assertions with its
processing model
WS-Policy and Use of Policies in Security
• Policy assertions governed by WS-PolicyAssertions
• Policy assertions can be specialized and documented in
dedicated specs (i.e. WS-Security Policy)
• WS-Policy Attachments allows to associate policy
expressions with different policy subjects
 i.e. XML messages and specific Web service endpoints
 Integrates w/WSDL documents so can apply spec’s XML attributes to
selected elements within WSDL doc
• WS-Policy helps verification code at server go away
 Instead, web service references XML-based policy file w/applicable security
requirements
Creating Policy Framework Files
1.
2.
3.
4.
Create policy framework shell
Implement set of applicable policy
assertions
Map policy expression file to
applicable SOAP endpoints
Configure the policy framework in
the Web service project
Policy Assertion
Description
Integrity
Specifies signature
format, with service
token type and hash
algorithm
Confidentiality
Specifies an
encryption format,
including hash
algorithm, security
token type and SOAP
elements that must
be encrypted
Specifies security
token type
SecurityToken
MessageAge
Specifies time period
which messages
considered current
and to be processed
WS-Trust and WS-SecureConversation
•
•
Personally, believe WS-SecureConversation one of most important WS-* specs
Allows Web services and clients to establish token-based, secure conversation
for duration of session

•
•
Very useful for parties that do not trust each other
WS-SecureConversation and WS-Trust provide means for client/server to
establish secure optimized comm channel for period of time
Secure Conversation




Based on established security tokens
Uses dedicated service token to generate signed service context, which is lightweight security
policy
Provides secure communication channel for duration of session
Provides optimized performance for session-oriented comm w/ multiple round-trips (use of
security context token)
WS-Trust and WS-SecureConversation
•
•
•
WS-Trust complements with protocols for requesting,
issuing, brokering security tokens
Operations to acquire, issue, renew & validate security
tokens
Sequence in Secure Conversation:
1. Client issues signed request to security token service provider for security
context token
2. Service provider verifies request and issues a security context token back to
client
3. Client and Web Service use the security context token to communicate
further
Agenda
• SOA for Dummies
• Introduction to WSE3
• WS-Security, WS-Secure Conversation with
WSE3
• Dive into Indigo
Indigo
• “The unified framework for building service-oriented
applications on the Windows platform”
• Unification
 Unifies (and subsumes) today’s distributed technology stacks
 Composable Functionality
 Cross-AppDomain, Cross-Machine and Cross-Internet
• Interop
 Cross platform interoperability
 Integration across Microsoft’s products
 Interoperability with today’s distributed stacks
• Service Orientation
 Service-oriented programming model
 Supports all features required by SOAs
The Road to Indigo
MessageOriented
Programming
WS-*
Protocols
Composability
Extensibility
ServiceOriented
Programming
Interop
AttributeBased
Programming
An Indigo Service
1. Service class (managed)
2. Host environment – application domain and
process
3. One or more endpoints that clients “talk” to
Services and Endpoints
Service
Endpoint
Contract: “What”
Binding: “How”
Address: “Where”
Endpoint
Contract: “What”
Binding: “How”
Address: “Where”
Endpoints
• Each endpoint specifies “ABC’s of Indigo”
 A = Address where endpoint lives
 B = Binding that tells how client can “talk” (i.e. HTTP, TCP)
 C = Contract identifies which methods endpoint exposes
• Basic unit of communication
• Format, send & receive messages over various
communication protocols
Service Contracts
• Indigo Service Contract is collection of operations that
endpoint communicates out
• Each operation a MEP
• Indigo service contract just class either marked with
ServiceContract attribute or implements interface
w/attribute
• All operations decorated with OperationContract auto
exposed as SOAP-callable operations
• Keep straight service from object!!
 Can expose different methods
Service Contracts
[ServiceContract]
public class CalculatorService
{
[OperationContract]
public double Add(double n1, double n2)
{
return n1 + n2;
}
[OperationContract]
public double Subtract(double n1, double n2)
{
return n1 - n2;
}
// Notice none here
public double Multiply(double n1, double n2)
{
return n1 * n2;
}
Data Contracts
•
•
•
•
•
New explicit model for serializable types
Enables loose coupling for CLR types
Version resilient by default
IJW with [Serializable] & ISerializable
Foundation for the future
Binding and Hosting
• Binding elements describe aspect of how endpoint
communicates to outside world
• Indigo provides standard set of bindings
• Can host app domain & process provided by WAS
(Windows Activation Service)
 IIS (like ASMX on IIS)
• Can also host in any app domain running in arbitrary
process
 Set up by calling Open on the instance of Generic ServiceHost<T> object
 Indigo will now automatically direct requests from clients to appropriate
methods in the Service class
Providing an Indigo Service
1. Define your Indigo service and implement
behavior
2. “Run” the service on some host
3. Advertise the Service
Consuming an Indigo Service
1. Create a Proxy for the Indigo Service
Application
2. Invoke a Service from the Client
Demo!
Basic Indigo Services and Clients
Preparing for Indigo Today
• Build services using ASMX (expose only ASMX service endpoints)
 Enhance using WSE 2/3
 Enables explicit boundary expressed in standard schema & communicate over open
standards boundaries (not so for ES & Remoting)
• Inside service, do your thing with layers but consider “Mini-services” to
align more with Indigo
• Use .NET Enterprise Services within your service…
 If you need ES functionality
 If you need fast/secure intra-farm ORPC
• Use .NET Remoting within your service…
 If you need lightweight CLR-CLR ORPC
 If need custom message formats on wire
 Only other case: communicate between 2 components in different AppDomains
inside the same process
• Note: Some of this material from Rich Turner – see
http://blogs.msdn.com/richardt/archive/2004/07/21/190742.aspx