Service Oriented Architecture and Windows Communication ...

694 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
694
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Service Oriented Architecture and Windows Communication ...

  1. 1. Service Oriented Architecture and Windows Communication Foundation (née Indigo) Michael Stiefel co-author Application Development Using C# and .NET www.reliablesoftware.com development@reliablesoftware.com New England Code Camp IV: “Developer’s Gone Wild”
  2. 2. 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”
  3. 3. 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”
  4. 4. 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”
  5. 5. 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”
  6. 6. 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”
  7. 7. 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”
  8. 8. 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”
  9. 9. 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”
  10. 10. 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”
  11. 11. Service vs. Object Services Objects Not new, but not familiar Well-understood Heterogeneous Environment Single Execution Environment Schema Type Might have long delays Assume fast, transparent network Loose Coupling / Messaging Compile /Link Time Binding Execution Time Binding Linkers and Loaders Addressing Object References / Addresses Security Throughout Usually at the Boundaries Model Real World Processes Service Implementation New England Code Camp IV: “Developer’s Gone Wild”
  12. 12. 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”
  13. 13. 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”
  14. 14. 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”
  15. 15. 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”
  16. 16. Basic Concepts • Host • Address • Binding • Contract • Endpoint = Address + Binding + Contract • Behavior • Channel New England Code Camp IV: “Developer’s Gone Wild”
  17. 17. Service Consumer and Provider Message Endpoint Service Consumer Service Provider Endpoint Host Endpoint = Address + Binding + Contract New England Code Camp IV: “Developer’s Gone Wild”
  18. 18. • Greeting Service Example New England Code Camp IV: “Developer’s Gone Wild”
  19. 19. 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”
  20. 20. 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”
  21. 21. 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”
  22. 22. 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”
  23. 23. 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”
  24. 24. • Loan Service Example New England Code Camp IV: “Developer’s Gone Wild”
  25. 25. 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”
  26. 26. • AutoInfo Example New England Code Camp IV: “Developer’s Gone Wild”
  27. 27. Pure Messaging • Interact with SOAP Headers – See Action manipulation • Create Body directly New England Code Camp IV: “Developer’s Gone Wild”
  28. 28. • Dispatch Example New England Code Camp IV: “Developer’s Gone Wild”
  29. 29. Diagnostics • Trace SOAP Messages • Trace Service, Client transitions New England Code Camp IV: “Developer’s Gone Wild”
  30. 30. • DispatchTracing Example New England Code Camp IV: “Developer’s Gone Wild”
  31. 31. 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”
  32. 32. • LoanServiceDuplex Example New England Code Camp IV: “Developer’s Gone Wild”
  33. 33. 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”
  34. 34. Bindings • Transport • Encoding • Protocols • Semantics New England Code Camp IV: “Developer’s Gone Wild”
  35. 35. Transports • TCP • HTTP • MSMQ • Named Pipes • Custom New England Code Camp IV: “Developer’s Gone Wild”
  36. 36. Encodings • Text • Binary • Custom New England Code Camp IV: “Developer’s Gone Wild”
  37. 37. Protocols • WS* • .NET • REST • POX • Custom New England Code Camp IV: “Developer’s Gone Wild”
  38. 38. Bindings in the Box Interop Security Session Transactions Duplex BasicHttpBinding BP 1.1 T WsHttpBinding WS T|S X X WsDualHttpBinding WS T|S X X X NetTcpBinding .NET T|S X X X NetNamedPipesBinding .NET T|S X X X NetMsmqBinding .NET T|S X X New England Code Camp IV: “Developer’s Gone Wild”
  39. 39. Semantics • Session • Duplex • Security • Transactions – (ACID, not WS-Business Activity) • Queued Delivery • Reliable Messaging New England Code Camp IV: “Developer’s Gone Wild”
  40. 40. • LoanServiceReliableMessaging Example New England Code Camp IV: “Developer’s Gone Wild”
  41. 41. Binding Configuration • Configuration Files • Requirements Specfied in Code – [ServiceContract] – [BindingRequirements] New England Code Camp IV: “Developer’s Gone Wild”
  42. 42. 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 Core W3C Candidate Recommendation 17 August 2005 New England Code Camp IV: “Developer’s Gone Wild”
  43. 43. ServiceEndpoint • Address (URI) • AddressProperties • Binding • Contract • Providers define Endpoint • Consumers target it New England Code Camp IV: “Developer’s Gone Wild”
  44. 44. 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”
  45. 45. IIS Hosting Address • http://machine-name [:port][/vdirpath] filename.svc New England Code Camp IV: “Developer’s Gone Wild”
  46. 46. 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”
  47. 47. 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”
  48. 48. 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”
  49. 49. 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”
  50. 50. Security Gates • Host – File, Url Permissions • Operation Contract / Message – Principal Permission • Imperative (Code) – System.Security New England Code Camp IV: “Developer’s Gone Wild”
  51. 51. Reliable Messaging • Create Session, guarantee message delivery [BindingRequirements(RequireOrderedDelivery = true)] New England Code Camp IV: “Developer’s Gone Wild”
  52. 52. 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”
  53. 53. OperationContext.Current • Host • IncomingMessageHeaders • InstanceContext • RequestContext • ServiceSecurityContext • SessionIdentifier • SupportingTokens New England Code Camp IV: “Developer’s Gone Wild”
  54. 54. 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”
  55. 55. Summary • WCF Unifies Microsoft Programming Model New England Code Camp IV: “Developer’s Gone Wild”

×