CSSE 477 – Intro to Service Oriented Architectures

1. Right – The basics of SOA, from a web site by ITT Technical Institute! New Rose CSSE competitor? http://technorati.com/technology/article/service-oriented-architecture/ CSSE 477 – Intro to Service Oriented Architectures Steve Chenoweth Monday, 10/31/11 Week 9, Day 1

2. Today • Let’s hear usability studies from the remaining teams • Architecture – What’s SOA all about? • No real addition to your project about it, but there is a small “project assignment” • This afternoon – Go listen to GE talk! • Tomorrow and Thursday – • More about SOA – tomorrow you get to be a new SOA developer! • Friday – • A day to work on your presentations for week 10

3. SOA: Let’s start with basic communications • There are two ways you can have something like “a text editor” -- • You get software for it, like Microsoft Word or Open Office, or • You just “run it” as a service, like Googledocs • These two alternatives have been around, as competing ways to deliver services, for a really long time! • E.g., in the telephone network – • A company’s offices could have their own little network with equipment right there (a little “switch” to connect employees), or • They could buy “Centrex” from the phone company, which provides that remotely.

4. Architecturally… • What are the issues with trying to put everything on the user’s machine? • Or, in general, having it all be “local” • Like on a single server close to you, say? And, • What are the issues with having things “distributed” so that you have to go to something remote frequently?

5. So, at any point in “history” • There’s a choice you have to make, as a systems architect – • What goes close to the users? • Or close to your own systems generally • And what do you rely on as a remote service? • A related financial choice often is, “What do you make or buy, and what do you lease from outside” –

6. SOA: The OO Dream Extended • In OO we had this dream of distributed processing.. • It was objects talking to objects across boundaries • Like, if you couldn’t find the service you wanted somewhere, you could find an alternative easily • Apps, and not just people, could do these searches and adjustments easily

7. But… Originally there were some serious issues! • You had to build your own networks • Half of everyone’s IT budget was phone lines, • They were slow, and • They were shared across organizations only in a limited way. And, • Objects couldn’t talk to other objects as easily as we had hoped! • Object definitions were proprietary, not shared.

8. The Internet made it seem possible! • Put OO and the Internet together, and you can picture…No reason why we can’t do this! • Like, people build families of objects, and they can all talk to each other easily • Say, in a supply chain, all the buyers and sellers can interact and make use of each other’s information. • What’s in your widget? • Oh, ok – How much?

9. Publisher / Subscriber? • We were looking for something kind of like CORBA, DCOM, etc., only with • More general standards for those pesky objects, and • Smaller pieces with more interactions

10. Everyone realized • You could also divide up what was on just one machine, • Like the pieces of an application, • Using a common style of interface like CORBA, • And then it was easier to make changes! • Everyone sent messages to each other in the same way, from one object to another, and • You could move things from one machine to another, as the system grew, etc. • What happened to the people who tried this?

11. The need was for interoperability • One service should be able to replace another • Much more so than existing ways allowed • A big part of this was competition – more particularly… • Users of services wanted competition among providers of services. • “If I don’t like your credit authorization service, I can (physically at least) switch to someone else’s tomorrow!

12. Also internal interoperability Within an organization… • I also want to be able to replace an old version of a service I use internally, • With a new version, via a standard interface to both. • And if I can’t replace them, I’d like to “wrap” them in some way that lets them interoperate with all my new stuff! • Say, • My own payroll system, or • One feature of that payroll system

13. The “Component revolution” helped • As late as 1990, most systems were entirely home-grown, above the OS, DB and networking layers. • This was replaced by the idea of buying “components” instead of building them. • Development organizations discovered it almost always was cheaper to buy something from a common source, if it was available. • Took advantage of “Myhrvold’s law” • Often “90% of what you needed” • Frequently could customize or wrap if needed to add things to it • Included – again – both whole systems and pieces as options

14. And XML helped • It turned out the Internet needed a more formal version of html – one that let you specify properties of things more clearly. • 1995ish – we got that with XML.

15. And the killer technology…? • Gotta be “Web services”! • These products have grown to include XML-based technologies for messaging, service description, discovery, and extended features. • (The current crop of these, like WSDL and SOAP, will surely be replaced eventually by even better tools!)

16. Web services provide • Pervasive, open standards for distributed computing interface descriptions and document exchange via messages. • Independence from the underlying execution technology and application platforms. • Extensibility for enterprise qualities of service such as security, reliability, and transactions. • Support for composite applications such as business process flows, multi-channel access, and rapid integration.

17. Thus, the idea of SOA “Service Oriented Architectures”: • Picture a world where you can use interchangeable components to build applications • Sometimes they are the whole thing • Sometimes they are little pieces • Sometimes with a lot of “glue” of your own • Sometimes not • And these components aren’t brought in when you “build” something • Instead, you attach to them at runtime! • They are “services” instead of “products”

18. The SOA sales pitch • Services are reusable business functionality with well-defined interfaces. • Service consumers are built using functionality from these. • At the provider’s end, the service interface and how it’s implemented – clearly separated  platform independence. • The whole SOA infrastructure allows for discovery, composition, and invocation of services.

19. Where’s the “architecture” come in? It’s how we use all this stuff to get application interoperability and reuse of assets: • A strong architectural focus, including governance, processes, modeling, and tools. • An ideal level of abstraction for aligning business needs and technical capabilities, and creating reusable, coarse-grain business functionality. • A deployment infrastructure on which new applications can quickly and easily be built. • A reusable library of services for common functions (like for different types of business functions). • Protocols -- primarily message-based document exchanges.

20. What are the “things” involved? • Products, standards and protocols support the communications: • Web services (HTTP, SOAP, WSDL) • Message-oriented middleware (IBM Websphere MQ, etc.) • Publish/Subscribe (Java Messaging Service, CORBA, etc.) • Infrastructure services to perform common tasks or satisfy QoS needs: • Security, discovery, data transformation, like HLT for health services.

21. What’s the architect do? • Oversees the development of reusable services, • Identifies a means to store, manage, and retrieve service descriptions when and where they are needed. • Defines a reusable services layer that insulates business operations such as “get customer” or “place an order” from variations in the underlying software platform implementations. • Just as Web servers and browsers insulate the World Wide Web from variations in operating systems and programming languages.

22. What’s the architect do? - cntd What are they looking for as they work: • Making reusable services • Which can be composed into larger services quickly and easily • Using external services instead of developing • Thus, “automation” of development • Agility to respond to changing conditions.

23. The IT world loves it! If all IT applications were to use a common programming interface and interoperability protocol, • The job of IT would be much simpler, • Complexity would be reduced, and • Existing functionality could be more easily reused. After a common programming interface is in place, through which any application can be accessed, • Existing IT infrastructure can be more easily replaced and modernized. • This is the promise that service-oriented development brings to the IT world.

24. The IT world loves it! - cntd • When deployed using SOA, services also become the foundation for more easily creating a variety of new strategic solutions, including: • Rapid application integration. • Automated business processes. • Multi-channel access to applications, including fixed and mobile devices.

25. The IT world loves it! - cntd • An SOA facilitates the composition of services across disparate pieces of software, whether • Old or new; departmental, enterprise-wide, or inter-enterprise; • Mainframe, mid-tier, PC, or mobile device, to streamline IT processes and • Eliminates barriers to IT environment improvements. • This “corporate advantage” is a driving force in making SOA happen for all of us!

26. MBA’s love it!

27. How is SOA development different? • Developers are “SOA users”. • A service is defined by the messages it exchanges with other services, rather than a method signature. • A service must be defined at a higher level of abstraction than an object because • It’s possible to map a service definition to a procedure-oriented language, or • To a message queuing system such as JMS or MSMQ, or • To an object-oriented system such as J2EE or the .NET Framework.

28. How is SOA development different? - cntd • A service normally defines a coarse-grained interface that accepts more data in a single invocation than an object and • It consumes more computing resources than an object because of the need to map to an execution environment, process the XML, and often access it remotely. • Services are designed to solve interoperability problems between applications and for use in composing new applications or application systems, but • Not to create the detailed business logic for the applications.

29. Development – what’s easy and hard? • Relatively easy to build apps and services that work with a particular infrastructure. • Designing a “good” service – maybe not so easy. • Composition – data and process mismatches. • Not many best practices – • What’s the right granularity? – larger yields incompatibilities. • What’s the right Quality of Service (QoS)?

30. Misconceptions – 1. SOA is a complete architecture • SOA is an architectural style • As per Bass’s Ch 2 description, you need to apply it to something and get down to implementation specifics to call it an “architecture” • So, you can’t buy “SOA” off-the-shelf. • Grace Lewis (SEI) hates it when people say something “has SOA,” like that’s all you need to say to describe it.

31. Misconceptions – 2. SOA solves all legacy-wrapping issues • Underlying systems still can have issues because of how they work. • Security • Error handling • Performance • Cost to integrate with SOA • Suitability of functionality versus the needs of SOA clients

32. Additional Misconceptions 3. “SOA’s all about standards, and standards are all you need.” • Wrong – Standards are still emerging. • Some overlap and conflict. • E.g., BPEL vs. WSCL vs. WS-Coordination. 4. “SOA is all about technology.” • It also changes organizational governance. • Lifecycle models are affected. • Many sources of knowledge  conflicts.

33. Additional Misconceptions - cntd 5. Service registry allows runtime binding. • Wrong – current technologies have not advanced to the point that this is possible in production environments. • Requires a common formal ontology by service providers and consumers in a domain. 6. “Testing SOA is like other testing.” • How do you do end-to-end testing with the real, invoked services, or test instances of them? • How do you anticipate usage patterns?

34. And • Not everything has to be a service! • Need to identify likely services, given available technology. E.g., good ones are • Reusable tasks • Those with multiple consumers • Need consumers to bind programmatically • Functions are essentially stateless • Request / response nature • Don’t require construction of complex consumers

35. Theory of SOA SOA requires 3 basic operations: • Service Discovery • Registries are queried to find desired services • Service Composition • Application/service consumers are built by integrating functions from these services • Business processes are “orchestrated” or “choreographed” as a composition of services • Service Invocation • Services are invoked and service code executed

36. Service Discovery • Static – How it’s done today – at design time • Developers discover services and get info • Write code to invoke the services • Dynamic – a research topic • Application discovers services and gets info • Obtains code to invoke these, and “knows” how to use • In-between techniques – Apps discover services, portals defined, or services have user interfaces

37. Service Discovery - cntd Typical sequence (say, for a Customer Management System): • Service consumer developers search the registry for services that are best suited • Is there a service that can return all customer information for a given Customer ID? • Services are registered in a Service Registry that is part of the SOA infrastructure • The Customer Management System registers its two services: • Customer Lookup • Customer Directory

38. What’s a Service Registry? • Contains info about available services • Specs (Contract) – required info • Description • Classification • Usage history • Test results • Performance metrics • Metadata • Documentation • A registry also can help keep track of service consumers • Understand required service level • Facilitate impact analysis • Notify of service change

39. Service Composition • The SOA infrastructure provides “business process management” (BPM) support. • Includes support for service composition to implement business processes. • The application service consumers are built by integrating functionality provided by services.

40. Service Invocation • In one option – a simple invocation pattern, where service consumers directly invoke services over a network. • Typically synchronous, direct request-reply connections. • Point-to-point

41. Service Invocation - cntd • In another option – service consumers invoke services via a middleware component supporting SOA environments, such as an Enterprise Service Bus (ESB). • TBOSS-ESB, etc. • A two-step process with QoS, Complex Event Processing, Routing, & Mediation in the ESB.

43. Web Services • Initially implemented using the WS* stack. • Described using WSDL: Web Services Description Language. • Data’s transmitted using SOAP, encoded in XML over HTTP. • Customers discover service registries via UDDI registries. • Orchestration and Choreography via BPEL: Business Process Execution Language and other software. • Turns Web Services into Business Processes, like transactions.

44. WSDL – an XML doc with: • Types– a container for data type definitions using some type system (such as XSD). • Message– an abstract, typed definition of the data being communicated. • Operation– an abstract description of an action supported by the service. • Port Type–an abstract set of operations supported by one or more endpoints. • Binding– a concrete protocol and data format specification for a particular port type. • Port– a single endpoint defined as a combination of a binding and a network address. • Service– a collection of related endpoints.

45. SOAP – how WS* messages go SOAP = Simple Object Access Protocol • A W3C specification • A SOAP message travels between SOAP nodes: • On a SOAP message path • From an initial sender through one or more intermediary nodes, • To ultimate receiver – who processes the message body.

48. WS* Web Services - Strengths • Uses HTTP and other commonly used protocols • Layered architecture with a wide range of capabilities • E.g., WS-Security, WS-Reliability, WS-Transaction • Support legacy reuse and interoperation • Flexibility in binding mechanisms • Multiple tools on the market to implement

49. WS* Web Services - Weaknesses • Perceived complexity and bias toward large software vendors • Concern about standardization • Lack of architectural coherence • Overwhelming number of standards • Performance issues • Large messages • XML parsing

50. Web Services - cntd • Recently, REST has become widely adopted: REpresentational State Transfer. • Every entity that can be identified is a “resource” • Each resource has a URI: Universal Resource Identifier • Resources can be interlinked • HTTP as primary transport mechanism • Every resource has the same interface, as defined by HTTP • GET, POST, PUT, DELETE • Transactions are stateless • REST is an architecture, not a protocol