1. Connected Applications Today Case Studies I Lawrence Wilkes

2. Deutsche Bank Deutsche Bank Global financial services group provide services in 70 countries Business Challenge Components calculate option pricing for equity derivatives Distribute components to local operations in a way that could be easily adopted for each market in which the set of calculators was being used Their derivatives calculators provide option prices as a web service hosted on Unix Using custom controls and Visual Studio.NET, a drag and drop toolkit was provided to its developers around the world.NET Framework provided: Seamless interoperability with Unix hosted services Encapsulation through componentisation development time reduced by 50% development time reduced by 50%

3. Global Pricing Calculation Architecture.NET.aspx.cs Client SDK using Custom controls Unix hosted equity option calculator Name Ticker CCY Exch F(x) Web Service

4. L’Oréal Before.NET No separation of elements in the page Logic and page design mixed together High costs of maintenance and change http://www.lancome.fr

5. L’Oréal Architecture.asp Transform Validate BizTalk Server SQL 2000 Web Service HTML XML ASP.NET Service Facade asmx Queue L’ Oréal Web Services Product Description SearchImages Request Further Info

6. L’Oréal Summary BizTalk Server and SQL 2000 used to implement XML product Catalogue ASP.NET separates user interface from XML data – using server controls Web Services integrate with retailers and suppliers BizTalk for XML transformation and integration "We expect.NET to deliver a 20 to 30 percent reduction in the total cost of ownership for our hundreds of Internet properties. In addition to lower development and deployment costs, our new solution will reduce ongoing administrative costs by making life much easier for our webmasters and marketing people.“ Jérôme Peyrelevade Head Technology Officer L'Oréal Internet and e-Business Group Architecture

7. Accor Services 3500 hotels in 88 countries, 46% market share, offering budget to luxury accommodations including travel agencies, restaurants, and casinos Accor swapped development from Java/WebLogic when Microsoft Consulting Services demonstrated the.NET development environment The task: Replace back-office systems with common library of business objects Streamline e-procurement for the chain of restaurants and hotels Manage sales and marketing campaigns for increased sales and incentives for sales staff

8. ASP.NET BizTalk SQL 2000 Windows 2000 Accor.NET Architecture Service Facade asmx Supplier E-procurement Sales Campaigns Business objects C# App Centre Web Service HTML XML

9. SQL 2000 Windows Server 2003.NET BTI UK Hotel Broker Hotels BTI Hotel Broker Hotel Broker Flight Broker Car Broker Corporate Travel Rules Maps Weather Driving Instructions Corporate Users XML Car Hire Web Service HTML XML Web Service GALILEO Web Services Reservation Builder Trip Planner Flight Information Itinerary Travel Codes Translator

10. BTI Benefits Call centre productivity increased by up to 40 per cent Agents concentrate on complex requests Supported infrastructure and lower cost of ownership Integration with other systems via Web services New automated services to customers

11. Building Connected Apps on the Microsoft Platform Nigel Watling nigelwa@microsoft.com Microsoft EMEA

12. Components, Services, Systems Do Foo Do Baz Do Bar Service Component System

13. Service Oriented Architecture Key Points SOA is an architectural approach to creating systems built from autonomous services i.e. it is a mindset NOT a technology It can be implemented using any technology A major leap forward in philosophy and approach to designing and building distributed, connected systems Leverages what we already know Evolves and consolidates all we’ve learned to date about designing & building distributed systems

14. Service-Orientation Tenets Philosophy of services Services have explicit boundaries Across boundaries we must have FORMAL interaction Services are autonomous Message based interaction with no implicit dependencies Services share contract and schema Require a formal, shared language for schema and contract Service compatibility is determined based on policy Require a formal, shared language and namespace for policy Tenet \Ten"et\, n. Any opinion, principle, dogma, belief, or doctrine, which a person holds or maintains as true. Source: Webster's Revised Unabridged Dictionary, © 1996, 1998

15. Why is SO important? Provides us with an opportunity to rethink how we design and architect tomorrow’s systems With Web services it enables a level of interoperability never before achievable Makes explicit some of the core assumptions that compromise today’s systems Particularly around boundaries and locality …

16. Practicalities Boundaries A SOA boundary is explicitautonomous, based on schema and contract for structure, and on policy for semantics Influenced by platform, deployment and trust Objects are appropriate within boundaries Services are appropriate across and within boundaries A SOA environment extends only as far as where we agree the boundary is How far do you want your boundary to extend?

17. Web Services Web Services Standards-based Messaging Web Services form a global infrastructure for message passing Interoperability through open standards Core set of standards has been built Industry is driving development of additional standards to complete the architecture Can be used with any architecture (not just SOA) e.g. RPC between components! On any hardware, any platform, any programming language Broad interoperability requires web services

18. What is a practical, broadly interoperable SOA? An applied approach to creating systems built from interoperable autonomous Web services Web services Communicate via SOAP message exchanges Are built to last Have a critical need for availability and stability Systems Are a set of Web services cooperating in a given task Are built to change Adapt to new services after deployment

19. SOA Implementation Systems and Services A system built using SOA principles which wants broad usage will: Build on the WS- protocols And use SOAP messages between services Internally a service can utilize whichever technologies and techniques are the most appropriate E.g. mainframe Choose your boundaries carefully

20. Microsoft Technologies What to use, where and when! There are many Microsoft technology choices for building SOA systems Which should you use, where and when?

21. ASMX ASP.NET Web Services ASMX is Microsoft’s recommended method for developing Web Services today ASMX gives great support for formal contract and schema expression (WSDL) ASMX doesn’t natively support the WS-* protocol family ASMX can be combined with WSE to get WS-* support

22. WSE Web Services Enhancements Getting started today? Use the evolving advanced feature set provided by WSE Early implementations of WS-* specifications WSE tracks the evolution of emerging WS-* protocols WSE builds on current Microsoft messaging technologies WSE can be used with ASMX for Web Services over HTTP WSE can be used standalone for Web Services over TCP/IP WSE’s supportability is 2+1 (standard+extended)

23. .NET Remoting.Net Remoting is an easy-to-use object remoting technology.NET Only.NET Common Type System (NOT XML Schema) Proprietary messages Third party bridging products No built-in security until.NET Framework 2.0 Can leverage IIS for transport-level security Or roll-your-own custom channel It requires tightly coupled implementation between participants, and is therefore particularly unsuited to SOA boundary implementation It is a reasonable technology to use for cross app-domain communication within the service boundary DON’T USE XPROCESS/XMACHINE Use ASMX or Enterprise Services

24. .NET Remoting and Web Services Working Side by Side Service Implementation Remoting Client Remoting Interface Web Service Client Web Service Interface

25. Don Box on.NET Remoting… From his blog on 26/4/04 The Good The transparent proxy (TP) /stack builder sink (SBS) infrastructure Allows you to construct an object reference for ANY CLR interface. Allows the CLR to marshal object references across AppDomains inside a process The technology is alive and well and a crucial part of the CLR. Indigo M5 uses this! The Bad The support for WSDL under the TP/SBS infrastructure is an architectural dead end The Ugly.NET Remoting assumes shared classes and shared assemblies between the two endpoints. Indigo exists to break this dependency. This is a profound architectural change. Custom transport channels are based on bytes. Indigo has a SOAP/Infoset-based architecture that is more general and will have a longer life span There are no plans to support the binary/TCP transport channel. It is one-off and proprietary. The TP/SBS infrastructure allows class-based remoting using MarshalByRefObject. Indigo does not require MBRO. Conclusion The real asset of.NET Remoting is the TP/SBS infrastructure. If you find yourself wanting to use it, do so with a clear conscience. If you're crossing host boundaries, ASMX is probably a better choice, both architecturally as well as in terms of tracking where the platform is headed in the next 2-10 years.

26. Enterprise Services ES offers rich enterprise system features ES is the programming model that will most resemble the Indigo programming model ES uses DCOM as its communication protocol DCOM is not suitable for spanning trust boundaries It is tightly coupled enough (because you have proxies/stubs) that you should avoid using it cross machine COM+ relies on closely coupled participant systems, and is unsuitable for expression of service boundaries. It is fine for use within a service boundary Just-in-time activation Declarative transactions Role-based security And more… PerformanceSecurity ACID transactions Object Pooling

27. .NET Enterprise Services Working Together Service Implementation Remoting Client Remoting Interface Web Service Client Web Service Interface ACID Transaction

28. MSMQ System.Messaging MSMQ is Microsoft’s Message Queuing technology Performant, reliable, durable messaging Rich administrative support Proven model No language for schema, contract, policy These are intuited, not interpreted Great to use within a service boundary System.Messaging is the.NET wrapper

29. SOA and MSFT Messaging Stacks ASMX and/or WSE for the boundaries ASMX, WSE,.NET Remoting, Enterprise Services, MSMQ inside the boundaries ASMX+/|WSE ASMX.Net Remoting Ent. Svcs MSMQ

30. Other Microsoft Web Services Solutions ATL Server and Managed C++ – ISAPI extensions SOAP Toolkit – deprecated by.NET No longer retires July 1, 2004 Standard support April 05, Extended April 07 SQL Server 2005 TDS only prior to SQL Server 2005 Now uses SOAP and HTTP via http.sys to go through firewalls #1 Recommendation Use ASMX + WSE to create Web services

31. Complementary Technologies Technology Map CLR Application CLR Remoting BizTalk CRM ERP Connectors… ASMX SOAP Clients Web Services Enterprise Services

32. BizTalk Server 2004 Overview Services must be agile Business Process Management Enterprise Application Integration Trading Partner Interaction BizTalk Server incorporates SOA paradigm Components are exposed and self-describing Robust support for long-running, asynchronous transactions Solutions are extensible and reusable Processes can be monitored in real time Can reconfigure any process activity without disrupting the process

33. BizTalk Server 2004 Faster development and deployment of business integration applications Microsoft Office access Vertical Market accelerators Enterprise class scalability Easy integration with Web services Extensive standards support

34. BizTalk Server 2004 Process Service Features Process Orchestration Rapidly develop integration services Transport abstraction Human Workflow Services Expose end user touchpoints Scalable long-running transactions Business Activity Monitoring

35. BizTalk Server 2004 Orchestration

36. BizTalk Server 2004 Infrastructure Service Features Security Encryption Authorization Single sign-on Reliable messaging Auto retry Secondary transports Auditing Message tracking Application data tracking

37. BizTalk Server 2004 Working Together BizTalk Server Web Service BAS IIS Web Service Client Application

38. SharePoint Portal Server & SharePoint Services Web-based Team and enterprise collaboration Audience targeting and personalization Combine team portals into enterprise portals SharePoint Services built on.NET framework Integrated with BizTalk Server Sites created in ASP.NET Web service and XML integration

39. Host Integration Server 2004 Technologies to Integrate IBM Hosts with New Solutions Developed using Microsoft Windows Lower Costs to Deploy Web and SOA Solutions Reduce Time to Market for Enterprise Devs Simplify and Secure Network Infrastructure Approaches and Methods of Integration Network and Security Data Access and Messaging Application to Application

40. The Role of Objects Reduce assumptions between services Builds on ideas from component software, distributed objects, and MOM Boundaries are explicit Opt in model Share schemas, not types Autonomous Security and failure isolation are a must Variable cost, explicit communication Independent deployment of client / Service Policy-based compatibility Assertions use stable global names Interaction Richness Reduced Assumptions Complete fidelity with local contract Customers have 20+ years of experience and have built intuition here Boundaries are harder to isolate Requires careful opting out Share types, not schemas Tightly Coupled Typically require deployment of both client and server in sync Assume cheap, transparent communication object identity and lifetime maintained by infrastructure Platform-based compatibility Assertions built into platform Service OrientationObject Orientation

41. Today’s Prescriptive Guidance Summary Build services using ASMX Enhance your ASMX service with WSE if you need the WSE feature set and 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

42. Developer Enablement Guidance Authorization and Profile Application Block Building Interoperable Web Services: WS-I Basic Profile 1.0 Web Service Façade for Legacy Applications Visual Studio.NET 2003 Foundation for XML WS programming model Key supported standards Attribute based development Schema driven XML serialization WS-I Basic profile compliant* Web Services Enhancements (WSE) 1.0 Foundation for advanced Web service support Improved extensibility WS-Security

43. Infrastructure And Business Process Guidance Information & Application Architecture for the Service-Oriented Enterprise Application Interoperability: Microsoft Application Interoperability: Microsoft.NET and J2EE Windows Server 2003 Metadata AD & ADAM Security Authorization Manager Registry & Discovery Enterprise UDDI QueuingMSMQHosting IIS 6.0 & Enterprise Services ManagementWMI BizTalk Server 2004 Connectivity (EAI/B2B) 350+ Adapters Native Web service support Business Process Orchestration Business Rule Engine Business Activity Monitoring Human Workflow Services Partner Management Security Single Sign-On Management SQL Server 2000 Web Services Support

44. Smart Client And Reach Office System 2003 XML meta and persistence format InfoPath for schema, template driven forms Native Web service consumer Visual Studio.NET integration Guidance Guidance Smart Client Offline Application Block Asynchronous Invocation Application Block Service Aggregation Application Block Sharepoint Portal Server for Office Windows Sharepoint Services.NET Compact Framework PocketPC and SmartPhone

45. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.