Service Oriented Architecture

1. Service Oriented Architecture Applying SOA - Services, Components, Objects... When to use what? Part 3 Adomas Svirskas Vilnius University October 2005

2. Agenda • Practical application of the SOA-based approach • Taxonomy of the services, components, objects • Service Oriented Analysis and Design (SOAD)

3. Evolutionary mission of SOA • Building an enterprise-scale software system is always a complex undertaking • Evolution is one of the critical aspects • Few serious systems, if any, are designed and build from ground-up (green-field) • The task of software architect is to reuse enterprise IT assets and integrate them into the new dimensions of business

4. What is Important? • When implementing an SOA solution the following aspects are important: • Holistic approach to the restructuring of enterprise IT assets • Virtualization of the assets on “what they do” basis • Understanding of interrelationships between services, components and objects

5. Why it is Important? • There are catches to avoid along the way: • An “SOA magic” might turn out as JBOWS (Just a Bunch of Web Services) [4] • Technocratic approach to bridging business with IT • Fragmentation “SOA like” efforts on departmental or application domain basis • As a result, no significant gain from SOA and gradual dismissal of it within an enterprise

6. JBOWS are here to stay for a while • According to a survey [5], only 29% of 480 respondents (corporate IT folks) rate their SOA developments as fairly mature • Reasons include: • Lack of general knowledge of SOA within their enterprise - cited by 17 percent • The challenge of quantifying the ROI around SOA - cited by 15 percent. • Issues with governing development standards within their enterprise - 12 percent

7. Architecting SOA-based systems • So, the field is not green for an SOA architect – the basics [6] apply, of course • More specifically: • Taking into account: • Operational systems layer assets • Enterprise component layer assets • Producing a set of loosely coupled, asynchronously communicating services with clear business-aligned interfaces • Easier said than done

8. Architectural Template for SOA An abstract view of SOA depicts it as a partially layered architecture of composite services. [1]

9. Services vs. Components [3] • Components and services, although similar… • Are blobs of code that can do something • Have interfaces that describe what they can do • Live in a process somewhere • Live to do the bidding of a client. • …are not the same • Have differing design criteria and different design patterns • Not every good component transformed into a service makes a good service.

10. Services vs. Components • The key differentiators: • Conceptual: Purpose and granularity • Coarse grained software services mapped to composable business services vs. finer grained components representing lower level functionality • Technical: location and environment [7] • Location refers to the relative locations of a component/service and its client (i.e. processes containing them) • Environment refers to the hosting runtime environment for the entity and the client (for example, J2EE application server, Microsoft’s .NET etc.)

11. Services vs. Components [7] • Services are useful for tying together autonomous systems; components for coordinating the process distribution within a system; objects for organizing the code within a process • “Objects share a common operating system process, components share a common hosting/runtime environment, and services share nothing but a common message format”

12. Services vs. Components • Computational efficiency: • Services are less efficient than components • Components are less efficient than objects • Development process: • Tools are the best for OOD, then CBD • IDE • Testing • Tools for (Web) Services development are catching up

13. Comparison (adapted from [7])

14. The Choice is not Tool-driven • The language and tools vendors have done us a great service by making it easy to create components and/or Web services from objects [7]. Too great job, in fact. • The tools vendors do not care that much about the choices between the entities • “Good fences make good neighbors.”

15. The Choice is not Tool-driven “… aš tik nesutinku, kad OOP netinka verslo sistemoms. pačios programos, kurios sudaro verslo sistemą gali ir tikriausiai turi būti įgyvendintos pasitelkus OOP, tačiau jų integravimui taikyti distributed objects ir rpc - netinkamas sprendimas. iki kursų maniau, kad gana svarbus rpc naudojimo pasiteisinimas - įrankių palaikymas, bet pamatęs, kaip weblogic workshop keliais pelės kliktelėjimais pagal nutylėjimą generuoja document/literal web servisus, manau, kad šiuo metu liekant prie rpc reikia tikrai svarių argumentų.” • http://pukomuko.lt/?item=newsitem&news=442

16. SO Analysis and Design (SOAD) • There is a need for a hybrid approach that combines elements of all of the disciplines, with a number of distinct, new elements. • The resulting, interdisciplinary OOAD method facilitating successful SOA deployments, referred to as Service-Oriented Analysis and Design (SOAD) [2]

17. SOAD Hierarchy SOA generally comprises stateless, fully-encapsulated, and self-describing services satisfying a generic business service that is closely mapped to the BPM [2]

18. SOAD Requirements [2] • There must be a structured way to conceptualize services: • OOAD gives us classes and objects on the application level, while BPM has event-driven process models. SOAD has the issue of gluing them together. • The method is no longer use case-oriented, but driven by business events and processes. Use case modeling comes in as a second step on a lower level. • The method includes syntax, semantics, and policies. This is required for ad hoc composition, semantic brokering, and runtime discovery.

19. SOAD Requirements [2] • SOAD must provide well-defined, quality factors and best practices (such as answering the granularity question). For example, Who is responsible for which portion of the work: the Developer, Architect, or Analyst? • The SOAD movement will also have to answer the question: What is not a good service? For example: anything that is not, or never likely to be reusable, probably does not make a good first-class SOA citizen (a service, that is). Another example is embedded, real-time systems with challenging, non-functional requirements, which cannot afford any XML processing overhead.

20. SOAD Quality Factors • Well-crafted services bring flexibility and agility to the business; they facilitate ease of reconfiguration and reuse through loose coupling, encapsulation, and information hiding. • Well-designed services are meaningful and applicable for more than enterprise application; dependencies between services are minimized and explicitly stated. • Services abstractions are cohesive, complete, and consistent; for example, one should think of the Create, Read, Update, Delete, and Search (CRUDS) metaphor when designing services and their operation signatures.

21. SOAD Quality Factors • The service naming is understandable for domain experts without deep technical expertise. • In a SOA, all services follow the same design philosophy (which is articulated through patterns and templates) and interaction patterns; the underlying architectural style can easily be identified (for example, during architecture reviews). • The development of the services and service consumers requires only basic programming language skills in addition to domain knowledge; middleware expertise is only required for a few specialists, that in an ideal world, work for tool and runtime vendors, and not for the companies crafting enterprise applications as SOAs.

22. SOAD Elements [2] • Service categorization and aggregation • Policies and aspects • Meet-in-the-middle processes • Semantic brokering • Service harvesting and knowledge brokering

23. Service Categorization and Aggregation [2] • Services have different uses and purposes; for example, software services can be distinguished from business services. Furthermore, atomic services can be orchestrated (composed) into higher level, full-fledged services.

24. Policies and Aspects • A service has syntax, semantics, and QoS characteristics that all have to be modelled; formal interface contracts have to cover more than the Web Services Description Language (WSDL) does. Therefore, the WS-Policy framework is an important related specification. • Business traceability is a desirable quality, in addition to the well-established principle of architectural traceability: it should be possible to directly link all runtime artifacts directly to the language a non-technical domain expert can understand.

25. Process – “meet in the middle” [2] • There are no green field projects in the real-world as legacy applications always have to be taken into account. Therefore, a meet-in-the-middle approach is required, rather than pure, top-down or bottom-up process. • The bottom-up approach tends to lead to poor business-service abstractions in case the design is dictated by the existing IT environment, rather than existing and future business needs. On the other hand, top-down processing might cause insufficient, non-functional requirement characteristics, and compromise other architecture quality factors

26. Semantic Brokering [2] • In any SOA context, a formal interface contract for the invocation syntax is important. The semantics issue (the meaning of parameters and so forth) has to be solved as well (domain modeling). This is key in any business-to-business (B2B) and dynamic invocation scenario. Such scenarios are cornerstones of the SOA vision of being flexible and agile in response to the new business needs in a world of mergers and acquisitions, business transformation, globalization, and so forth.

27. Service harvesting and knowledge brokering • This is a knowledge management and lifecycle issue: how can services successfully be prepared and made available for reuse once they have been conceptualized? • Services should be identified and defined with reuse (and harvesting) as one of the main driving criteria of the SOA in mind. If a component (or service) has no potential for reuse, then it should probably not be deployed as a service. It can be connected to another service associated with the enterprise architecture, but will not be a service in its own right. • However, even if reuse is planned for right from the beginning, the process still has to formalize the service harvesting process. Service usage by more than one consumer is an explicit SOA design goal. A build-time service registry, for example, an enterprise-wide UDDI directory can be part of the answer.

28. The Layers of Design The layers of design [2], [3]

29. Conclusions • SOAD is not a trivial exercise • SOAD is only beginning to establish itself • Importance of SOAD cannot be underestimated

30. References • [1] Arsanjani, A. Service-oriented modeling and architecture. 2004. http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/ • [2] Zimmerman, O. et al. Elements of Service-Oriented Analysis and Design. 2004. http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/ • [3] Brown, A. et al. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications • [4] McKendrick, J. The Rise of the JBOWS Architecture (or Just a Bunch of Web Services). 2005. http://www.webservices.org/ws/content/view/full/72091 • [5] McKendrick, J. Survey: JBOWS will be around for a long time. 2005. http://blogs.zdnet.com/service-oriented/?p=445 • [6] Wiegers, K. Requirements When the Field Isn't Green. http://www.processimpact.com/articles/reqs_not_green.html

31. References • [7] Sessions, R. Fuzzy Boundaries: Objects, Components, and Web Services. http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=246