Service Oriented Architecture and Windows Communication

Preview:

DESCRIPTION

 

Citation preview

New England Code Camp IV: “Developer’s Gone Wild”

Service Oriented Architecture and Windows Communication Foundation (ne ́e Indigo)

Michael Stiefelco-author Application Development Using C# and .NET

www.reliablesoftware.comdevelopment@reliablesoftware.com

New England Code Camp IV: “Developer’s Gone Wild”

Goals– Understand what is meant by a Service

Oriented Architecture (SOA).– Understand the relationship between a SOA

and a Web service.– Understand the basics of Windows

Communication Foundation (WCF)

New England Code Camp IV: “Developer’s Gone Wild”

Fundamental Principle

• Service Oriented Architecture (SOA) is driven by business needs, not technical advancements– Contrary to the view of many vendors

• SOA is about approaches and principles, not fixed technical approaches or patterns– Leads to fuzziness that makes technical types

and geeks unhappy and wary

New England Code Camp IV: “Developer’s Gone Wild”

Architecture

• Study of the principles of design, construction, and esthetics of buildings

• The profession of designing, constructing, and ornamenting buildings

• The structure and organization of a particular building or class of buildings

• The confusion for developers is that SOA is about the first definition not the last.

New England Code Camp IV: “Developer’s Gone Wild”

SOA is an Architectural Style

• Principles, esthetics vary over historical periods– Gothic, Greek, Bauhaus, Greek revival, Victorian

• Principles, esthetics vary over types of artifacts– Military architecture, naval architecture, software architecture

• SOA is about the principles and esthetics of constructing loosely coupled, reusable application-agnostic services within the modern business environment

New England Code Camp IV: “Developer’s Gone Wild”

Modern Business Environment• Business cannot afford to rebuild every

application from scratch• Consumer and business customers’ demands

change quickly over time• Businesses depend on vendors and suppliers• SOA is about developing and connecting to

loosely coupled, reusable application-agnostic business services, not just building an application that meets specific business functionality or goals such as ROI or cost effectiveness

New England Code Camp IV: “Developer’s Gone Wild”

Document Centered Processing• Exchange Documents/Messages,

– No access of remote objects– Contract: content, order of versioned documents and

messages– Can contain their own state

• Security travels with the Message• Services made compatible through policy• Transactions do not span long running services

with no guaranteed connection– Compensating transactions

New England Code Camp IV: “Developer’s Gone Wild”

What is a Service?

• Explicit boundaries for code and data• Connected through versioned messaging• Can be rewritten or redeployed

independently• Interaction through schema and contracts,

not implementation– Clients and Services can evolve separately

New England Code Camp IV: “Developer’s Gone Wild”

Policy

• Provides service constraints.– X.509 Certificates are required for

identification– Applicant must have certain net worth– Response time or service availability

New England Code Camp IV: “Developer’s Gone Wild”

Object Oriented Evolution• Reuse through Inheritance

– Fragile Base Class Problem– “Inheritance Breaks Encapsulation”

• Reuse through Interface and Composition– Design Patterns

• Reuse through Templates• Dynamic Interface, Behavior Reuse with

Contracts– Next step in black box reuse

New England Code Camp IV: “Developer’s Gone Wild”

Service vs. ObjectObjectsWell-understoodSingle Execution EnvironmentTypeAssume fast, transparent networkCompile /Link Time BindingLinkers and LoadersObject References / AddressesUsually at the BoundariesService Implementation

ServicesNot new, but not familiarHeterogeneous EnvironmentSchemaMight have long delaysLoose Coupling / MessagingExecution Time BindingAddressingSecurity ThroughoutModel Real World Processes

New England Code Camp IV: “Developer’s Gone Wild”

Trust Boundaries

• The major driving force for SOA is the need to effectively map IT infrastructure to changing business needs.– Integrating systems from different divisions of

the same company or different businesses• Interoperability drives SOA.• With different organizations, services must

cross trust boundaries.

New England Code Camp IV: “Developer’s Gone Wild”

Web Services and SOA

• Enabling technology for SOA:– Independent of execution environment – Provide a clear boundary between services.– Allow for loose coupling– Set of industry standards

New England Code Camp IV: “Developer’s Gone Wild”

Windows Communication Foundation

• Unified Programming Model– ASMX, WSE, MSMQ, Remoting, Enterprise

Services• WS-* specification support• REST, POX support• Programming Model

– Imperative, Declarative, Configuration

New England Code Camp IV: “Developer’s Gone Wild”

Caveat• September CTP code

– Beta 1 (outdated) docs– Update subset of Beta 1 samples

• Concepts• Implementation

New England Code Camp IV: “Developer’s Gone Wild”

Basic Concepts

• Host• Address• Binding• Contract• Endpoint = Address + Binding + Contract• Behavior• Channel

New England Code Camp IV: “Developer’s Gone Wild”

Service Consumer and Provider

Service Consumer Service Provider

Endpoint

Endpoint

Message

Host

Endpoint = Address + Binding + Contract

New England Code Camp IV: “Developer’s Gone Wild”

• Greeting Service Example

New England Code Camp IV: “Developer’s Gone Wild”

Host• Controls service providers lifetime

– Self Hosting, within a managed application• Console, Windows Forms, Windows Service

– IIS Hosting– Windows Activation Services (WAS)

• ServiceHost class

New England Code Camp IV: “Developer’s Gone Wild”

Contracts

• Define the programmatic format of the interaction between the client and server.– Service Contract and Data Contract

• work together as Data and Operations in a class– Message Contract

• XML Messaging

New England Code Camp IV: “Developer’s Gone Wild”

Service Types

• Typed– can be simple or class data types

• Untyped– Send and receive Message instances,

approximates SOAP message• Typed Message

– Custom message classes derived from Message

New England Code Camp IV: “Developer’s Gone Wild”

Service Contract

• Annotate Interface or Class, Operations– Analogous to WSDL portType

[ServiceContract][BindingRequirements(RequiredOrderedDelivery=true)]public interface IHotelReservation{

[ServiceOperation]bool IsRoomAvailable(string startDate, int numberDays);

}

New England Code Camp IV: “Developer’s Gone Wild”

Data Contracts• Map CLR types to XML Schema types[DataContract]public class Stock{

[DataMember] public string symbol;[DataMember] public decimal price;

}[Service Contract]public interface StockTrading{

[OperationContract] bool BuyStock(Stock stock, decimal bidPrice);}

New England Code Camp IV: “Developer’s Gone Wild”

• Loan Service Example

New England Code Camp IV: “Developer’s Gone Wild”

Message Contracts (Typed Message)[MessageContract]public class PurchaseOrder{

[MessageHeader] public string orderId;[MessageBody] public OrderItem item;

}

[ServiceContract]public interface IContract{

[OperationContract]void SendPurchaseOrder(PurchaseOrder message);

}

New England Code Camp IV: “Developer’s Gone Wild”

• AutoInfo Example

New England Code Camp IV: “Developer’s Gone Wild”

Pure Messaging

• Interact with SOAP Headers– See Action manipulation

• Create Body directly

New England Code Camp IV: “Developer’s Gone Wild”

• Dispatch Example

New England Code Camp IV: “Developer’s Gone Wild”

Diagnostics

• Trace SOAP Messages• Trace Service, Client transitions

New England Code Camp IV: “Developer’s Gone Wild”

• DispatchTracing Example

New England Code Camp IV: “Developer’s Gone Wild”

Message Exchange Patterns

• Built from asynchronous one-way message.– LoanService Example

• Synchronous Request / Reply– Other examples

• Duplex / Asynchronous Callback

New England Code Camp IV: “Developer’s Gone Wild”

• LoanServiceDuplex Example

New England Code Camp IV: “Developer’s Gone Wild”

Binding• Specify aspects of service that do not relate to

the capabilities of your service.– Example:

• Capability: given a stock symbol, provide a quote• Basic Profile Binding: HTTP, text encoding, only transport

security, no duplex messaging

• Change binding without affecting capabilities• Service Quality may require certain bindings (i.e.

encryption or transactions)

New England Code Camp IV: “Developer’s Gone Wild”

Bindings

• Transport• Encoding• Protocols• Semantics

New England Code Camp IV: “Developer’s Gone Wild”

Transports

• TCP• HTTP• MSMQ• Named Pipes• Custom

New England Code Camp IV: “Developer’s Gone Wild”

Encodings

• Text• Binary• Custom

New England Code Camp IV: “Developer’s Gone Wild”

Protocols

• WS*• .NET• REST• POX• Custom

New England Code Camp IV: “Developer’s Gone Wild”

Bindings in the Box

Interop

Security

Session

Transactions

Duplex

BasicHttpBinding BP 1.1 TWsHttpBinding WS T | S X XWsDualHttpBinding WS T | S X X XNetTcpBinding .NET T | S X X XNetNamedPipesBinding .NET T | S X X XNetMsmqBinding .NET T | S X X

New England Code Camp IV: “Developer’s Gone Wild”

Semantics

• Session• Duplex• Security• Transactions

– (ACID, not WS-Business Activity)• Queued Delivery• Reliable Messaging

New England Code Camp IV: “Developer’s Gone Wild”

• LoanServiceReliableMessagingExample

New England Code Camp IV: “Developer’s Gone Wild”

Binding Configuration

• Configuration Files• Requirements Specfied in Code

– [ServiceContract]– [BindingRequirements]

New England Code Camp IV: “Developer’s Gone Wild”

Endpoint Reference“A Web service endpoint is a (referenceable)

entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint.”

Web Services Addressing 1.0 CoreW3C Candidate Recommendation 17 August 2005

New England Code Camp IV: “Developer’s Gone Wild”

ServiceEndpoint• Address (URI)• AddressProperties• Binding • Contract• Providers define Endpoint • Consumers target it

New England Code Camp IV: “Developer’s Gone Wild”

URI• http://rfc.net/rfc3986.html• ftp://ftp.is.co.za/rfc/rfc1808.txt• news:comp.infosystems.www.servers.unix• tel:+1-816-555-1212 telnet://192.0.2.16:80/ • urn:oasis:names:specification:docbook:dtd:xml:4.1.2

New England Code Camp IV: “Developer’s Gone Wild”

IIS Hosting Address• http://machine-name [:port][/vdirpath] filename.svc

New England Code Camp IV: “Developer’s Gone Wild”

Base Address

• Address can be specified relative to a base address:– “http://localhost/WeatherService/”– “”– “Temperature”

• A service can have multiple base addresses

New England Code Camp IV: “Developer’s Gone Wild”

Specify Address in Config File<endpoint

configurationName=“WeatherEndpoint”address = “http://localhost/WeatherService/service.svc”binding = “basicHTTPBinding”contract = “IWeather” />

New England Code Camp IV: “Developer’s Gone Wild”

Behaviors

• Service Internals– Concurrency– Instancing– Faults, Exceptions– Metadata customization– Instance Pooling– Impersonation, Protection, Authorization– AutoEnlist, Isolation, AutoComplete

New England Code Camp IV: “Developer’s Gone Wild”

Security• Message Exchange• Resource Access• Audit Resource Requests• Built-In

– Anonymous Credentials– X509 Certificates

• Sign with sender’s credentials• Encrypt with recipient's credentials

• Focus on Credentials, not Tokens• Extensible

New England Code Camp IV: “Developer’s Gone Wild”

Security Gates

• Host– File, Url Permissions

• Operation Contract / Message– Principal Permission

• Imperative (Code)– System.Security

New England Code Camp IV: “Developer’s Gone Wild”

Reliable Messaging

• Create Session, guarantee message delivery

[BindingRequirements(RequireOrderedDelivery = true)]

New England Code Camp IV: “Developer’s Gone Wild”

Programming• Metadata Exchange

– svcutil http://localhost/LoanService/service.svc/out:LoanProxy.cs /noConfig

– Can generate proxy, custom configuration

New England Code Camp IV: “Developer’s Gone Wild”

OperationContext.Current

• Host• IncomingMessageHeaders• InstanceContext• RequestContext• ServiceSecurityContext• SessionIdentifier• SupportingTokens

New England Code Camp IV: “Developer’s Gone Wild”

ServiceDescription• Metadata about Service• Behaviors

– Program Requirements, Instance mode, concurrency, transaction level, security

• Endpoints– Addresses to which services can be addressed

• Type– CLR type implementing the service

• Validators– Enforce Binding requirements

New England Code Camp IV: “Developer’s Gone Wild”

Summary

• WCF Unifies Microsoft Programming Model

Recommended