WEB 301 Service Oriented Architecture and Web Services

WEB 301 Service Oriented Architecture and Web Services Yasser Shohoud Program Manager XML Messaging Microsoft Corporation

Goals Define SOA and understand the benefits Understand how to create SOA applications Understand how Web services enable SOA

What is Service Oriented Architecture? “A service-oriented architecture is a design for an application that is built using a service technology, e. g. , Web services” -- Tim Ewald “SOA is the about thinking of your system as independent pieces that provided services instead of components that provide methods, regardless of how those services are exposed. Thinking in terms of services gives you a much better handle on what’s important in your system and what are implementation details” -- Chris Sells “SOA is distributed application architecture that is flexible and resilient in the face of change” -- Me

Services and components A component is a reusable unit of deployment Software components are the Integrated Circuits of software Components may be deployed with the app that uses them Services are not Components are typically logic only They rely on data that is not packaged with the component Services are typically logic + data packaged together

Shift To A Service-Oriented Architecture From To Function oriented Build to last Process oriented Build to change Prolonged development cycles Incrementally built and deployed Application silos Tightly coupled Object oriented Known implementation Orchestrated solutions Loosely coupled Message oriented Abstraction

An Example Application Using Component-Based Architecture An Asset management application User enters company’s assets into the system System depreciates assets and displays results

Version 1 Architecture Static Diagram

Version 1 Architecture Sequence Diagram

Version 1 Code Let’s look at the code

What Changes Things never stay the same Business requirements change New business processes New rules Or simply an extension of the app to automate more processes Underlying data changes Data schema may be revised to accommodate new requirements These may be performance requirements New consumers for your backend Someone else is building an app and wants to use your backend services They have slightly different requirements Your existing consumers should not be affected

Version 2 Requirements We want to support multiple depreciation tables Federal and State We want to specify the date that the asset was purchased We want the results to include specific dates for depreciation periods e. g. 6/2003 $312. 09 7/2003 $298. 32

Version 2 Architecture Static Diagram

Version 2 Architecture Sequence Diagram

Version 2 Code Let’s look at the code Note that existing consumers (the app client) had to change May not be a big deal if you own the consumer and you are rolling out a new version But this doesn’t lend itself to SOA Not resilient in the face of change Too much of the implementation shows through

SOA Principles Loose coupling is important Consumers must not be forced to evolve as the services evolve Any exposed types must be extensible To allow for independent versioning You cannot share types and be loosely coupled Requiring a consumer to deploy some of your types means you are tightly coupled

What Are Web Services? A way of exposing functionality using a set of interoperable standards Services and consumers exchange messages based on general-purpose protocols that define the format of those messages Independent of the programming language used for the software generating or consuming such messages No shared types (unless you intentionally share them)

Web Services Architecture Security Management Reliability Business Process Transactions … Applications & Application Infrastructure Metadata Connected Applications Foundation … Transports Messaging XML HTTP TCP SMTP

The Same Example Application Using Service Oriented Architecture Start by defining the data exchanged This is your contract Build in a version flag Allow for extensibility Build a service that exposes this data Can be a Web service Do not require consumers to use the same types used by the service Focus on the data, not the types

Version 2 Application Using Service Oriented Architecture Extend the contract By leveraging extensibility point from V 1 Retain the extensibility point for Version 3! Revise service code to exhibit V 2 behavior Only if received data is V 2 V 1 consumers get V 1 behavior, V 2 consumers get V 2 behavior Resilience in the face of change!

So how to be SOA Look at the existing and new/desired set of applications and group them into logical services Data in/Data out When building a service, think of all other services you interact with as black boxes that provide data transformations Define the data exchange between services – this is your contract Allow for versioning and extensibility Web services and SOA If done right, Web services can easily yield SOA apps The key is loose coupling

Resources http: //msdn. microsoft. com/webservices Newsgroups microsoft. public. dotnet. framework. webservices. enhancements Real World XML Web Services Addison Wesley, 2002

Ask The Experts Get Your Questions Answered Web Services Booth ATE booth 19/20 Tuesday 5 pm – 6 pm Wednesday 11 am – 12 noon

evaluations

Community Resources http: //www. microsoft. com/communities/default. mspx Most Valuable Professional (MVP) http: //www. mvp. support. microsoft. com/ Newsgroups Converse online with Microsoft Newsgroups, including Worldwide http: //www. microsoft. com/communities/newsgroups/default. mspx User Groups Meet and learn with your peers http: //www. microsoft. com/communities/usergroups/default. mspx

© 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.

Appendix: Some definitions Remote Procedure Calls Invoking a procedure on a remote object Typically involves instantiating a remote object, calling a method and getting a return value Messaging Sending a message (data) to a receiver No implied response, no implied remote object