Connected Systems and Service Oriented Architecture Francesco Albano Enterprise Technical Evangelism Manager Developer & Platform Evangelism Division Microsoft Italy Agenda Service Orientation Web Services Architecture Technology Roadmap 2 Sound Familiar? “… I need to bring 50 new services to market in next 12-18 months” APPLICATIONS AND SERVICES “… 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” NETWORK AND BACK-END ELEMENTS Current infrastructure does not have the agility to keep up with business objectives 3 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. 4 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 5 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 8 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 noninteroperable… 9 Shift To Service Orientation From To Connections = cost Function oriented Build to last Prolonged development Connections = value Process oriented Build for change Incrementally deployed Application silos Tightly coupled Object oriented Orchestrated solutions Loosely coupled Message oriented 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 11 Service Orientation – Core Tenets Explicit Boundaries Autonomous Negotiation Via Policy Exposed Schema and Contract Message Driven Reuse & Dynamic Meaningful Information 12 Service Orientation – Key Concepts Applications Operational Requirements State composed of manage enforce Policies have governed by Services bound by exchange Message Exchange Pattern Contracts describe contain Messages is a set of Schemas define structure of 13 Service Orientation Business Process View Coarse Grained Web Service Operations Finer Grained Internal Service Operations Fine Grained Object and database calls Business Component Business Component Consumer Application Business Process 14 Service Orientation Required Capabilities Security Reliability Transactions Discovery Management Transport independence Interoperability Process orchestration 15 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 16 Unified Connectivity Less overhead, reduced surface area Consistent programming model Native interoperability EJB MQ DCOM Your Application ODBC 17 Abstraction Enables you to more gracefully decompose your application Enables you to extend and optimize your processes Business Processes Your Application Business Process Business Processes 18 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 19 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 20 Reuse Decomposition promotes reuse and enables more dynamic business processes Requires you to embrace a business process model 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 . 3.3. Procurement 3.3.1 Sourcing and Supplier Contract Management 3.3.2 Purchasing Request Resources Manage Requisition Approva Processl Create Purchase Requisitions Acquire/Purchase Choose or Default Supplier for Goods Perform Encumbrance Check Create Auction Bids Resources Manage Purchase Item Catalog Manage RFI/RFQ/ RFP process Verify/ Negotiate Price Purchase Indirect Materials Purchase Outside Vendor Services Manage Automatic Replenishment Manage Purchasing Methods Consolidate Approved Requisitions by Supplier Purchase Capital Goods Manage Open to Buy/Blanket POs Create Purchase Orders Purchase Direct Materials & Supplies Track Open POs Approve & Validate Contract Payments Manage Suppliers Manage Supplier Relationships Track Supplier Commitments Maintain Supplier Catalog Manage Buyer Performance Provide Supplier Self-Help 3.3.3 Receiving of Indirect / Capital Goods and Services 21 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? 22 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 23 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 24 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 Challenges with Multiple This leads people to build very simple applications Messages since only then can they cope with the failure complexity… Service-A Sender Service-B C B A C A B Receiver Problem !!! 25 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 Naturally Idempotent Read Record X Not Idempotent Withdrawing Idempotent $1 Billion Baking a cake starting with a shopping list (if you don’t worry Not Idempotent about money) Baking a cake starting from ingredients Idempotent If not yet withdrawal #XYZ then withdraw $1 Billion and label as #XYZ 26 Service-Oriented Analysis Issues Entity Identification Entity Factoring Service Identification Service Factoring Process Specification Endpoint (Touchpoint) identification Role Mapping SLAs … Information Architecture Clients and Agents Technology Architecture 27 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 … Process Service Document A Document C-1 Document C-2 Contracts Document B Either C-1 or C-2 Service Process 28 Service Operations Issues Security Access control Monitoring Management QoS and SLA enforcement Versioning Scalability Dealing with unreliability Exception routing Caching Sign Service Log Message Processing Infrastructure Encrypt Authorize Serialize Reliable messaging Audit Deserialize Message Processing Infrastructure Authenticate Service 29 Simplifying The Interaction Of Business Analysts And Developers Business analyst builds the specific business process bidirectional collaborative Developer ties processes in with systems and other processes 30 One Developer Experience Leverage existing skills Harness the .NET framework Build with standards 31 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 32 Building Connected Systems Best Tool for Web Services Interoperability Web Services Third party Management Products LOB Apps 390/AS400 Windows Clients RDBMS Other Clients LDAP Mobile Devices` UNIX VPN Netware Firewall Identity Management Programming Language Security Data Applications Industries Network Legac yInfrastructure 33 Visual Studio Visual Studio Visual Studio Team Architect Team Developer Team Test Application Designer Dynamic Code Analyzer Load Testing Logical Infra. Designer Static Code Analyzer Manual Testing Deployment Designer Code Profiler Test Case Management Unit Testing Code Coverage Class Designer Visio and UML Modeling Team Foundation Client (includes CAL) Visual Studio Professional Edition Visual Studio Team Foundation Change Management Reporting Integration Services Big Build Work Item Tracking Project Site Project Management Visual Studio Industry Partners Process and Architecture Guidance Visual Studio Team System 34 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 36 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.