Service Oriented Architecture and Windows Communication ...
description
Transcript of Service Oriented Architecture and Windows Communication ...
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
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