Introduction to SOA with an Eye Towards Indigo

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), Navi. Site, BCGI, Pacific Mind. Works § Designed and implemented Groove Toolkit for Microsoft Visual Studio. NET (JOLT Winner) • Speaker for VSLive!, Dev. Teach, 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 WSE 3 • WS-Security, WS-Secure Conversation with WSE 3 • 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. ” - Rich. Turner 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, J 2 EE, 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 WSE 3 • WS-Security, WS-Secure Conversation with WSE 3 • Dive Into Indigo

WS-Security, WS-Trust, WS-Secure Conversation Reliable Messaging Transactions WS-Reliable. Messaging 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-Reliable. Messaging 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/oasis 200401 -wssecurity-secext-1. 0. xsd WS-Security. Policy WS-Secure. Conversation 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-Security. Assertions (Turnkey Security Scenarios) • Support for updated WS-Addressing, WS-Security, WSTrust and WS-Secure. Conversation • 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. Services 3 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 VS 2005 and. NET Framework 2. 0 Support § Quick. Start 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 • Web. Services. Client. Protocol class exposes WSE input/output filters to ASP. NET web service clients § Extends base class for Web service proxies System. Web. Services. Soap. Http. Client. Protocol • Ensures WSE filters have chance to process SOAP message • Have to change base class of your web service proxy to Web. Services. Client. Protocol § Easiest way to use WSE Settings tool • Web. Services. Client. Protocol proxy base class implemented by two communication classes: § Soap. Web. Request § Soap. Web. Response

WSE Integration with ASP. NET • Soap. Web. Request parses request stream with SOAP message into instance of Soap. Envelope class • Key player in config with ASP. NET pipeline is Soap. Context class § Records Web specification options and later makes them available to WSE filters for processing Soap. Context request. Context = Request. Soap. Context. Current; • Refer again to picture

Configuring WSE 3

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 FilesMicrosoft WSEv 3. 0SamplesSample Test CertificatesReadme. htm

And Now the X. 509 Certificate Tool

Demo! Adding WSE 3 to a Web Service

Agenda • SOA for Dummies • Introduction to WSE 3 • WS-Security, WS-Secure Conversation with WSE 3 • 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, X 509 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 (Username. Token) Digital certificate such as X. 509 Kerberos token (Microsoft form) Custom Binary token

Creating Username-Password Token using Microsoft. Web. Services 2. Security; using Microsoft. Web. Services 2. Security. Tokens; using Microsoft. Web. Services 2. Security. X 509; Username. Token token; string username = Environment. User. Name; byte[] password. Bytes = System. Text. Encoding. UTF 8. Get. Bytes( username); Array. Reverse( password. Bytes ); string password. Equivalent = Convert. To. Base 64 String( password. Bytes ); token = new Username. Token( username, password. Equivalent, Password. Option. Send. None ); service. Proxy. Request. Soap. Context. Security. Tokens. Add(token); service. Proxy. Request. Soap. Context. Security. Elements. Add( new Message. Signature( token ) ); Stock. Quote[] quotes = service. Proxy. Stock. Quote. Request( symbols );

Creating X. 509 Token using Microsoft. Web. Services 2. Security; using Microsoft. Web. Services 2. Security. Tokens; using Microsoft. Web. Services 2. Security. X 509; X 509 Security. Token token = App. Base. Get. Client. Token( false ); X 509 Security. Token token = null; X 509 Certificate. Store store = X 509 Certificate. Store. Current. User. Store(X 509 Certificate. Store. My. Store ); X 509 Certificate. Collection certs = store. Find. Certificate. By. Key. Identifier( Convert. From. Base 64 String( key. Identifier ) ); if (certs. Count > 0) { token = new X 509 Security. Token( ((X 509 Certificate) certs[0])); } service. Proxy. Request. Soap. Context. Security. Tokens. Add( token ); service. Proxy. Request. Soap. Context. Security. Elements. Add( new Message. Signature( 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-Policy. Assertions • 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 Policy Assertion 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 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 Security. Token Message. Age Specifies time period which messages considered current and to be processed

WS-Trust and WS-Secure. Conversation • • Personally, believe WS-Secure. Conversation 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-Secure. Conversation 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-Secure. Conversation • • • 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 WSE 3 • WS-Security, WS-Secure Conversation with WSE 3 • 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-App. Domain, 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 Message. Oriented Programming WS-* Protocols Composability Extensibility Service. Oriented Programming Interop Attribute. Based 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”

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 Service. Contract attribute or implements interface w/attribute • All operations decorated with Operation. Contract auto exposed as SOAP-callable operations • Keep straight service from object!! § Can expose different methods

Service Contracts [Service. Contract] public class Calculator. Service { [Operation. Contract] public double Add(double n 1, double n 2) { return n 1 + n 2; } [Operation. Contract] public double Subtract(double n 1, double n 2) { return n 1 - n 2; } // Notice none here public double Multiply(double n 1, double n 2) { return n 1 * n 2; }

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 Service. Host 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… 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 App. Domains inside the same process • Note: Some of this material from Rich Turner – see http: //blogs. msdn. com/richardt/archive/2004/07/21/190742. aspx