1. Connected Systems and Service Oriented Architecture Francesco Albano Enterprise Technical Evangelism Manager Developer & Platform Evangelism Division Microsoft Italy

2. 2 Agenda Service Orientation Web Services Architecture Technology Roadmap

3. 3 Sound Familiar? Current infrastructure does not have the agility to keep up with business objectives APPLICATIONS AND SERVICES NETWORK AND BACK-END ELEMENTS “… I need to bring 50 new services to market in next 12-18 months” “… I need to be driving $X00 million in revenue from new services in the next two years” “… it costs me $2 million to launch each service” “…It takes too much time and energy to bring even a simple service to life”

4. 4 What Is SOA? – Concepts Systems built from autonomous services A service is a program you interact with via message exchanges Services are built to last Availability and stability are critical A set of deployed services is a system An SOA is an orchestrated sequence of messaging, transformation, routing and processing events in which XML technologies expose the message content and the components that operate on the messages.

5. 5 Services  Objects Different deployment model Services are hosted, rather than forward-deployed Encapsulation at the interface, rather than the implementation Opportunity for interception and pipeline processing Opportunity for context- and content-sensitive routing Integration by Design All platforms can consume contracts and messages Opportunity to develop common entity model with marketplace partners

6. 6 Three Reasons for Using Services Autonomy of Applications Independent Development and Evolution Clarifies Encapsulation and Privacy of Data Separation of Biz-Process and App Allow Separate Development of Biz-Process Apps Gravitate to Managing Resources Enabling IT Infrastructure Surround the App (Service) in Predictable Way Connect the App (Service) into IT Infrastructure

7. 7 Three Categories of Service Use Building New Solutions With Services Independent Pieces Within Apps Independent Development and Maintenance Scale-Out Cleaving Apart Existing Apps Disentangling the “Big Ball of Mud” Cleaving Together Existing Apps Connectivity B2B: Business-to-Business EAI: Enterprise Application Integration Business Process Tap Into IT Infrastructure

8. 8 Baseline Standards – Web Services 1.0 Web Services are here today! Web services core: XML 1.0 (second edition) Base encoding for documents SOAP 1.1 Base encoding for messages WSDL 1.1 Description of web services UDDI 2.0 (API 2.04, data structure 2.03) Directory for finding service descriptions HTTP 1.1 Message transfer

9. 9 Great Baseline Specification But… Solutions have become more complex and need standards beyond this baseline Need higher lever functionality to support Enterprise Applications Security – Authentication and Authorization Routing Reliable Messaging Transactions Today these types of services can be implemented however they are usually some-what proprietary and often non- interoperable…

10. Shift To Service Orientation Connections = cost Function oriented Build to last Prolonged development From To Connections = value Process oriented Build for change Incrementally deployed Application silos Tightly coupled Object oriented Orchestrated solutions Loosely coupled Message oriented

11. 11 Service Orientation A service oriented architecture (SOA) significantly elevates the abstraction level for code re-use It allows applications to bind to services that evolve and improve over time without requiring modification to the applications that consume them Evolution not revolution

12. 12 Service Orientation – Core Tenets Explicit Boundaries Autonomous Negotiation Via Policy Reuse & Dynamic Exposed Schema and Contract Message Driven MeaningfulInformation

13. 13 Services Message Exchange Pattern describe OperationalRequirements enforce State manage Applications composed of Messages exchange is a set of Contracts bound by contain Schemas define structure of governed by Policies have Service Orientation – Key Concepts

14. 14 Service Orientation Business Process View Business Component Business Process Consumer Application Finer Grained Internal Service Operations Coarse Grained Web Service Operations Fine Grained Object and database calls

15. 15 Service Orientation Required Capabilities Security Reliability Transactions Discovery Management Transport independence Interoperability Process orchestration

16. 16 SOA – Current Standards Addressing these Application Interoperability areas WS-* Specifications Co-authored, (inc. MS, IBM, BEA, Verisign, SAP, Tibco) WS-Routing WS-Referral WS-Inspection WS-Security WS-Attachments WS-Coordination WS-Transaction WS-SecureConversation WS-SecurityPolicy WS-Policy WS-PolicyAttachment WS-PolicyAssertions WS-Addressing WS-ReliableMessaging

17. 17 Unified Connectivity Less overhead, reduced surface area Consistent programming model Native interoperability Your Application EJB MQ DCOM ODBC

18. 18 Business Processes Your Application Abstraction Enables you to more gracefully decompose your application Enables you to extend and optimize your processes Business Process

19. 19 Dynamic Discovery enables you to add services and consume services at “run-time” Policy enables services to dynamically calibrate and optimize overtime Guaranteed Delivery PKI Windows Credentials Guaranteed Delivery Windows Credentials Custom Credentials

20. 20 Resilient Schema provides a mechanism to decouple database, programming and “wire” format – this makes your application more resilient to change Coarse grain messaging enables loose coupling Business Process <ORDER>…..</ORDER> <ITEMS>…..</ITEMS> 1 Shoes 12.99

21. 21 Reuse Decomposition promotes reuse and enables more dynamic business processes Requires you to embrace a business process model 3.3. Procurement 3.3.1 Sourcing and Supplier Contract Management 3.3.3 Receiving of Indirect / Capital Goods and Services 3.3.2 Purchasing 000197 TBLEDIT SECTION. 000198******************************000199* 000200 DISPLAY ROOM-TOTAL-NUM(TBL-IDX). 000201 DISPLAY TBL-IDX. 000202 MOVE ROOM-TOTAL-NUM(TBL-IDX) TO WK-ALL. 000203 MOVE ROOM-RSV-NUM(TBL-IDX) TO WK-RSV. 000204 PERFORM RITU-COMP. 000205 MOVE WK-ALL TO POW-0001. 000205 MOVE TBL-IDX TO POW-0002. 000205 MOVE 1 TO POW-0003. 000205 CALL "_XPOWTABLESETNUMERICTO" USING BY VALUE ROOMTBL 000205 BY REFERENCE POW-0001 BY VALUE POW-0002 POW-0003.

22. 22 Design Considerations Things we should be thinking about: Security Transactions and SOA  What does it mean to think about transaction in an SOA world  How do we delineate transaction boundaries  What infrastructure support can we expect Idempotency of Services  Reliability issues make us assert that services should be idempotent. Data fidelity between services  Canonical Schema … goals and challenges Processes  The end goal are declarative processes… how do we get there?

23. 23 Security and SOA Need not be part of message Part of an infrastructure service It means more than just authentication Authorization Encryption Standards (WS-*) are still evolving to date

24. 24 Transactions and SOA: Issues Atomic transaction are singularities Locking makes them appear to be at a single point in time Two-phase commit removes distribution concerns The new challenges happen when spreading work across space and time Different services are in different spatial locations Work across different messages gets processed at different times Commutativity helps relax space and time By reordering with acceptable answers, it’s OK Note that DB write is not commutative

25. 25 Challenges with Multiple Messages Any request may arrive multiple times Sometimes after quite a while You might be a few messages farther along when an old one arrives The combinatoric complexity can be staggering This leads people to build very simple applications since only then can they cope with the failure complexity… Service-A Sender Service-B Receiver ABACAABC Problem !!!

26. 26 Idempotence Requests get lost… Gotta retry them to handle lost requests Requests arrive more than once… Those pesky retries may actually arrive Idempotent means it’s OK to arrive multiple times As long as the request is processed at least once, the correct stuff occurs In today’s internet, you must design your requests to be idempotent Naturally Idempotent Sweeping the floor Idempotent If not yet withdrawal #XYZ then withdraw $1 Billion and label as #XYZ Naturally Idempotent Read Record X Not Idempotent Baking a cake starting from ingredients Idempotent Baking a cake starting with a shopping list (if you don’t worry about money) Not Idempotent Withdrawing $1 Billion

27. 27 Service-Oriented Analysis Issues Entity Identification Entity Factoring Service Identification Service Factoring Process Specification Endpoint (Touchpoint) identification Role Mapping SLAs … Entity Services Process Services Infrastructure Services Clients and Agents Technology Architecture Information Architecture Activity Services

28. 28 Service-Oriented Design Issues Schema definition Message definition Contract definition Message handling Process management Transaction model Operational compliance Exception handling Message to Object mapping Refinement of Analysis … Contracts Service Process Document A Document C-1 Document C-2 Document B Either C-1 or C-2 Process

29. 29 Service Operations Issues Security Access control Monitoring Management QoS and SLA enforcement Versioning Scalability Dealing with unreliability Exception routing Caching Service Message Processing Infrastructure Serialize Encrypt Sign Deserialize Authenticate Authorize Audit Log Reliable messaging

30. 30 Simplifying The Interaction Of Business Analysts And Developers Developer ties processes in with systems and other processes bidirectional Business analyst builds the specific business process collaborative

31. 31 One Developer Experience Leverage existing skills Harness the.NET framework Build with standards

32. 32 Business Rules/Policy Use business process rules for simple cases or complete inference engine for more complex scenarios Rules change more often than processes Business rules provide increased flexibility Rules are abstracted from process and user code

33. 33 UNIX LDAP RDBMS Netware 390/AS400 Third party Management Products VPN Firewall Web Services LOB Apps Windows Clients Mobile Devices` Other Clients Building Connected Systems Best Tool for Web Services Interoperability NetworkInfrastructure DataManagement Applications Programming Language Legac y SecurityIdentity Industries

34. 34 Visual Studio Team System Change ManagementWork Item TrackingReportingProject Site Visual Studio Team Foundation Integration ServicesProject Management Process and Architecture Guidance Dynamic Code Analyzer Visual Studio Team Architect Static Code AnalyzerCode ProfilerUnit TestingCode CoverageVisio and UML ModelingTeam Foundation Client (includes CAL)Visual Studio Professional EditionClass DesignerLoad TestingManual TestingTest Case ManagementApplication DesignerLogical Infra. DesignerDeployment Designer Visual Studio Team Developer Visual Studio Team Test Visual Studio Industry Partners Big Build

35. 35 Understanding ROI of an SOA Infrastructure services Unify management processes Vendor-delivered at relatively low cost Extremely leverageable across applications Entity services Hide complexity of storage Protect databases from compatibility deadlock Highly leverageable across applications Activity services Single implementation of common transactions Moderately leverageable across applications Process services Disintermediation New frontier for process automation

36. 36 Closing Comments Service-orientation allows an organization to get control of unmanageable IT assets Once in control, you can Optimize Orchestrate Open access points to processes Create agility Top down or bottom up, SOA is a path to better alignment of business and technology

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