1 / 37

Connected Applications and Indigo

Connected Applications and Indigo. Felipe Cabrera Architect Microsoft. 1. Agenda. Recap of service-orientation trend Web Services Architecture Indigo Prescriptive guidance Q&A and Feedback. 2. Old IT Functional islands Built to spec Constrains business IT-business “alignment”

garth-porter
Download Presentation

Connected Applications and Indigo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Connected Applications and Indigo Felipe Cabrera Architect Microsoft 1

  2. Agenda • Recap of service-orientation trend • Web Services Architecture • Indigo • Prescriptive guidance • Q&A and Feedback 2

  3. Old IT Functional islands Built to spec Constrains business IT-business “alignment” IT accountable Cost driver Technology adjunct New IT Everything connected Built for change Empowers business IT and business are one Joint accountability Value driver Business platform IT as Business Value Driver

  4. Representing Data • Today • Non-standard data representations • Mostly human “Trim-and-Shim” to integrate • Beginnings of standardization • Web services foundation • Need industry standards • Demand for business process • Going forward • Industry de facto standards • Increased compatibility • More sophisticated business process

  5. 2000+ Web Services Service-Oriented Solutions Late 1990s Web technologies appear e.g. HTTP, HTML, XML Early 1990s Application integration technologies appear Pre-1990s Custom, static B2B Integration Business Benefit The Evolution to Services 5

  6. Toward Service-Oriented Solutions • Service-orientation is not new • Academic OS community has written about them at least since the 70s • Messaging has been broadly enabled since BSD 4.2 • Has been practiced in large enterprises for many years • On a wide range of hardware/software platforms • Important Complement to Object-Orientation • Learns from Components, Distributed Objects, and Message-Oriented-Middleware • Service-orientation has had false starts • CORBA • RMI • DCOM • … 6

  7. Service-Oriented Architecture • Boundaries are explicit • Services are autonomous • Services share schema and contract • Not class • Services establish explicit relationships • Service compatibility is based on policy

  8. New Success Factors • Better economics • Hardware advances make XML processing possible • Adopting the Internet model • Autonomy is central to success • Heterogeneity is a given • Enabling real interoperability • More principled architectural approach • Secure, reliable, transacted, asynchronous messaging • Use of metadata • Policies to express capabilities and requirements • Tools • Design, develop, debug, deploy 8

  9. Microsoft Activities Microsoft is working in different fronts to make service-orientation ubiquitous • SOAP, WSDL, UDDI, HTTP, XML • .NET (2000) • Web Service Architecture based on a WS-* family of specifications (2001 - 2004) • Web Service Enhancements (WSE) (2003) • WSE V2 (2004) • Indigo Beta (2004) 9

  10. Agenda • Recap of service-orientation trend • Web Services Architecture • Indigo • Prescriptive guidance • Q&A and Feedback 10

  11. Design Principles • Modular and composable • Factored to stand alone or work together • General-purpose • Agnostic to place it is running or originated • Standards-based • Multi-vendor interoperation is critical • Federated • No central point of administration, control, failure 11

  12. Architecture Approach • Single universal model for all interactions • Scale (process, machine, cluster, Intranet, Internet) • Node types (clients, servers, devices) • Trust boundaries (may be mutually suspicious) • Execution instances (asynchronous) • Versioning and deployments (loosely coupled) • Implementation stacks (OS, language, …) • Must • Provide interoperability • Achieve wide adoption 12

  13. “Scales Away” spans organizations & geographies “Scales Out” by adding machines “Scales Up” on large systems “Scales In” on a machine “Scales Down” to devices A Universal Architecture for Web Services Security Reliable Messaging Transactions Routing … Messaging Infrastructure Distributed applications Vertical processes Embedded systems Network equipment … 13

  14. WS Architecture EvolutionSecure, Reliable, Transacted Jan/Feb 2004 WS-Eventing WS-BusinessActivity WS-Discovery July 2003 WS-Federation March 2003 WS-ReliableMessaging WS-Addressing RM Roadmap March 2004 WS-MetadataExchange April 2002 WS-Security and Security Roadmap September 2003 WS-AtomicTransaction WS-Coordination SRT WS Whitepaper December 2002 WS-Policy WS-Trust WS-SecureConversation UDDI SOAP WS-I 2000 August 2002WS-TransactionWS-Coordination WSDL

  15. Web Services Specifications DevelopmentProcess Feedback and Interop Workshops Specification Published Revise Specification WS-I Standards Org Participation

  16. Feedback Workshops: • Are open to everyone • Need to sign workshop feedback agreement • Goals: • Get feedback on technology • Our experience is that they: • Yield well-engineered technology • Provide fastest time to market • Specification is revised based on feedback

  17. FeedbackWorkshops March 2004 WS-Transaction February 2004 WS-Eventing July 2003 WS-ReliableMessaging February 2003 WS-Policy and WS-Trust November 2003 WS-Federation 2002 March 2003 WS-Policy and WS-Trust Q2 2004WS-SecureConversationWS-TrustWS-FederationWS-Discovery

  18. Interoperability Workshops: • Open to teams with implementations • Goal: • Demonstrate interoperability • Our experience is that they: • Help refine the important scenarios • Ground the development efforts • Specification revised based on interoperability feedback

  19. Interoperability Events& Workshops Nov 2003 WS-Trust WS-SecureConversation (workshop) September 2003 Bill Gates (Microsoft)Steve Mills (IBM) March 2004 WS-Federation Passive Profile (workshop) SOAPBuilders 2002 December 2002CDBi - EMEA October 2003 WS-ReliableMessaging (workshop) Q2 2004WS-SecureConversationWS-TrustWS-ReliableMessagingWS-PolicyWS-AtomicTransactionWS-BusinessActivityQ3 2004WS-Discovery July 2003Catalyst(Burton conference) September 2003 OASISWS-Security August 2002XML Web Services One (East)

  20. Agenda • Recap of service-orientation trend • Web Services Architecture • Indigo • Prescriptive guidance • Q&A and Feedback 20

  21. What Is Indigo? • A set of Windows features for building and running service-oriented applications in managed code • Available in Longhorn timeframe • Available for Longhorn, Windows XP, Windows Server 2003 • A unified programming model and runtime • Across Microsoft’s existing distributed technologies • Across hosting models • Across node types • Across different levels of scale

  22. Longhorn Architecture 22

  23. Indigo (1/2) • Provides the interconnection fabric • Supports fine-grain composition of features • It is a platform with architected extensibility • Separates development of core functionality and deployment considerations • Like durability, or service topology • Exploits SOAP for transport independence • Includes the ability to transfer metadata 23

  24. Indigo (2/2) • Enables pervasive transactional behavior with a light-weight transaction manager • Deploys reliable-messaging in the low-end • Has a light-weight publish/subscribe infrastructure that is extensible • Topic management is layered • Provides a powerful “filter engine” to enable content-based message dispatch 24

  25. 25

  26. 1 line of security code 1 line of reliable messaging code 1 line of transaction code Total count: 3 Secure, Reliable, Transacted Indigo [Confidentiality] [Reliability(Guarantees.ExactlyOnce | Guarantees.InOrder)] [Service] class HelloService { [TransactionCoupling( TransactionCouplingOptions.Required)] [ServiceMethod] String Hello(String Greeting) { return Greeting; } } 26

  27. Agenda • Recap of service-orientation trend • Web Services Architecture • Indigo • Prescriptive guidance • Q&A and Feedback 27

  28. Indigo And Unification ASMX and WSE .NET Remoting Enterprise Services System.Messaging Simple ConfigInteroperableService-Oriented Broad VisionExtensibility Object-Oriented AttributesTransactionsComponents QueuingReliable MsgDurable Msg Indigo Indigo is a superset of the capabilities of our existing stacks

  29. Preparing For Migration:Know Your Boundaries • Application boundaries • Platform • Deployment • Trust • Across boundaries use services • Within a boundary both services and objects are appropriate

  30. Today’s Prescriptive Guidance • Build services using ASMX • Enhance your ASMX service with WSE if you need the WSE feature set and you can accept the support policy • Use object technology in a service’s implementation • Use Enterprise Services if • You need ES rich feature set • You are communicating between components on the local machine and have performance issues with ASMX or WSE • Use .NET Remoting if • You need to integrate with an existing proprietary protocol • You are communicating in-process, cross app domain • Use System.Messaging if you need the reliable messaging and queuing features in MSMQ 30

  31. Today’s Caveats • ASMX • Avoid or abstract using low-level extensibility such as the HTTP Context object • .NET Remoting • Avoid or abstract using low-level extensibility such as .NET Remoting sinks and channels • Enterprise Services • Avoid passing object references inside of ES • Do not use COM+ APIs – use System.EnterpriseServices • Do not use MSMQ APIs – use System.Messaging 31

  32. The WSE Speedboat • If you can get value out of a jump-start use Web Services Enhancements • PSS calls are supported • Has shorter life-span as product • Targeted to ‘Elvis’ and ‘Einstein’ 32

  33. Q & AandFeedback When in doubt look in http://msdn.microsoft.com/webservices 33

  34. WSE v2.0: Enhanced Security • Trust Issuing Framework (WS-Trust) • Secure Conversation (WS-SecureConversation) • Roles based authorization • Security Policy (WS-SecurityPolicy) 34

  35. WSE v2.0: Policy Driven Architecture • Beyond WSDL, what else is needed to describe a Web service? • Security requirements • Reliable messaging assurances • Protocol versioning • Etc… • These other attributes of a service can be described with WS-Policy • XML-base language • Complex: <Or>, <ExactlyOne>, etc… • WSE provides a Policy Framework with send-side and receive-side policy support 35

  36. WSE v2.0: SOAP Messaging • WSE offers four classes for messaging • SoapSender and SoapReceiver • One way messages • Low-level • SoapClient and SoapService • One-way and two-way • Uses SoapSender/SoapReceiver • Offers XML serialization support • Operation dispatching 36

  37. WSE v2.0: Multiple Hosting Environments • Applications can be hosted in multiple environments: ASP.NET, .exe, NT Service, WinForms, etc. • Support for multiple transports • In-process communication • Raw TCP • HTTP • Asynchronous support 37

More Related