SOA Part1 Lecture 3

1. SOA Part1 Lecture 3 Dr. Withalm 19-Nov-14

2. Lectures at the University of Bratislava/Autumn 2011 19.09.2011 Lecture 1 The long Way from OO to SOA & WEB- Services 26.09.2011 Lecture 2 Semantic WEB & SOA-Technological Basis 10.10.2011 Lecture 3 SOA-Basing on J2EE & SOA-Focus on Business Processes 17.10.2011 Lecture 4 B2B Frameworks and related Standards 14.11.2011 Lecture 5 WEB 2.0 & GRID & Cloud Computing Dr.Withalm

3. Today’s Agenda • Overview of SOA • SOA and WS and related Technologies • Future of WEB Applications • Event-Driven Business Processes Dr.Withalm

4. Summary of first lecture • Progress in Architecture are primarily enabled by technology • i.e. distributed computing by PC & Ethernet • Distributed computing encouraged Middle ware • i.e. RPC, CORBA, DCOM-which work efficient in EAI-projects • Middle ware is kept enclosed within companies mainly because of “closed” ports • i.e. most serious obstacle when deploying CORBA applications in IAI projects • EJB tried to combine strenghts of ORB and TP • Overcoming the performance issue which requested huge programming efforts in CORBA applications • EJB made a first “implicit” step towards services • i.e. Session Beans-whenever their focus was mainly IT-focused and not business oriented. Dr.Withalm

5. Summary of lecture 2 • Business needs request Web Services • EAI : enables the integration of different applications within a company • Prevailing standards/technologies are CORBA, COM,.. • Web Portals: enable Internet users to order products/services • Prevailing standards/technologies are HTTP, CGI, Servlet, Applets • Web Services: enable different applications to order products/services • Standards are the dark side of WS • Different standardization bodies: influenced by the big vendors • Most used and established are : SOAP, WSDL, and UDDI • SOA: enables not only synchronous mode • Semantic Web: Ontology, Agents and Languages as OWL, RDF • Ontology: most likely to be established in specific domains • Obstacles : not only technical but also political Dr.Withalm

6. Service-Oriented Architecture • Developers will shift their focus to business processes and away from software functionality. Software will become a facilitator of rapid business change, not an inhibitor. • The value creation in software will shift to subscription services and away from packaged software, and to composite applications (i.e., best of breed) and away from monolith suites. (Source: Gartner August 2005) Dr.Withalm

7. Service Oriented Architecture (SOA)/1 • The term Service-Oriented Architecture (SOA) expresses a software architectural concept that defines the use of services to support the requirements of software users. • In a SOA environment, nodes on a network make resources available to other participants in the network as independent services that the participants access in a standardized way. • Most definitions of SOA identify the use of Web services (using SOAP and WSDL) in its implementation. • However, one can implement SOA using any service-based technology. Dr.Withalm

8. Service Oriented Architecture (SOA) /2 • Unlike traditional object-oriented architectures • SOA comprise loosely joined, highly interoperable application services. • Because these services interoperate over different development technologies (such as Java and .NET), the software components become very reusable. • SOA provides a methodology and framework for documenting enterprise capabilities and can support integration and consolidation activities. • SOA is not a product, although several vendors offer products which can form the basis of a SOA. Dr.Withalm

9. Service Oriented Architecture (W3C) Service Transport Description A distributed system, consists of discrete software agents that work together to implement some intended functionality. Those agents in a distributed system communicate by hardware/software protocol stacks. Dr.Withalm

10. SOA Core Principles • Business Driven • The business drives the services, and the services drive the technology. • Bussiness Agility • Business agility is a fundamental business requirement. • Constant Change • A successful SOA is always in flux. Dr.Withalm

11. Business Driven • The business drives the services, and the services drive the technology. • In essence, services act as a layer of abstraction between the business and the technology. • The service-oriented architect must understand the dynamic relationships between the needs of the business and the available services on the one hand, as well as the technical underpinnings that offer the layer of abstraction required by the services. Dr.Withalm

12. Business Agility • Business agility is a fundamental business requirement. • Instead of dealing with concrete requirements from business, SOA considers the next level of abstraction: • The ability to respond to changing requirements is the new ''meta-requirement.'' • The entire architecture -- from the hardware on up -- must reflect the business agility requirement. Dr.Withalm

13. Constant Change • A successful SOA is always in flux. • To visualize how a SOA is supposed to work, it is better to think of a living organism or an ecosystem rather than the traditional ''building a house'' metaphor that gave software architecture its name. • IT environments are in a constant state of change, so the work of a service-oriented architect is never done. Dr.Withalm

14. The Service Fabric • All different services available inside or outside an organization can be seen as a large network of computing resources where each node is providing a distinctive service to users and programs alike – the network becomes a service fabric – the ecosystem for the enterprise. Dr.Withalm

15. The New Application • The application as a network of services - the whole is more than the sum of its parts… Dr.Withalm

16. Vision • The future of the application is the virtual collection of services based on the Service Oriented Architecture developed and enhanced on demand and made available for service consumption in the service fabric of the Internet of tomorrow. Dr.Withalm

17. Service Categories • User (Interface) Services • Business (Logic) Services • Data (Backend) Services Dr.Withalm

18. Business Service Business Service User Service Business Service User Services Dr.Withalm

19. Business Services • The programmatic access of a service and its (business) functionality is the main aspect of a service - often called a Business Logic Service. • This Business Service has to provide a distinctive service to its service consumers and can utilize other services to fulfill its task. Business Service Dr.Withalm

20. Data Services • The data store is accessed through standardized protocols and is exchanging data in XML format. Data (Backend) Service Business Service Dr.Withalm

21. Service Manager Pattern • The service manager acts not only as a proxy for the business component • but depending on the capabilities of the web server and component container • might also manage several other activities • important to the delivery of web service • such as data and protocol translation, security, or state management. Service Client Service Manager Service Implementation Dr.Withalm

22. Aggregation Business Service Business Service Business Service Business Service Dr.Withalm

23. Messages Integration Data Store Business Service Component Dr.Withalm

24. Orchestration Business Service Business Service Business Service Business Service Dr.Withalm

25. Services Orchestration and Choreography /1 • No service is an island. • The key point about service-oriented computing is • that involves extended, loosely coupled activities • among two or more autonomous business partners. • Such activities can be thought of • as (business) processes that engage several services in a manner • that brings about the desired (business) outcome. Dr.Withalm

26. Services Orchestration and Choreography /2 • Web services are rapidly emerging as the most practical approach • for integrating a wide array of customer, vendor, and business-partner applications. • While many companies have begun to deploy individual Web services, • the real value will come when enterprises can connect services together, • providing higher value to an organisation. Dr.Withalm

27. Services Orchestration and Choreography /3 • In order to communicate and integrate services • for achieving a collaboration between enterprises, • it will be necessary to coordinate them, • which involve the necessity of offering support to the services composition. • Early experience shows that to make the most of new Web services investments • there must be a standard approach to Web services composition. Dr.Withalm

28. Services Orchestration and Choreography /4Orchestration/1 • Refers to an executable business process • that may interact with both internal and external Web services. • Orchestration describes how Web services can interact at the message level, • including the business logic and execution order of the interactions. Dr.Withalm

29. Services Orchestration and Choreography /5Orchestration/2 • These interactions may span applications and/or organisations, • and result in a long-lived, transactional process. • With orchestration, the process is always controlled • from the perspective of one of the business parties. • It takes the view of a process as a program or a partial order of operations • that need to be executed. Dr.Withalm

30. Services Orchestration and Choreography/6Choreography/1 • More collaborative in nature, • where each party involved in the process • describes the part they play in the interaction. • Choreography tracks the sequence of messages • that may involve multiple parties and multiple sources. Dr.Withalm

31. Services Orchestration and Choreography/7Choreography/2 • It is associated with the public message exchanges • that occur between multiple Web services. • this takes the view of a process as being • a set of message exchanges between participants. Dr.Withalm

32. Services Orchestration and Choreography/8 Dr.Withalm

33. Services Orchestration and Choreography/9 • Orchestration differs from choreography in that it describes • a process flow between services, • controlled by a single party. • More collaborative in nature (see above Figure), • choreography tracks the sequence of messages • involving multiple parties, • where no one party truly “owns” the conversation. Dr.Withalm

34. Services Orchestration and Choreography/10 • It could be distinguished as Orchestration defines procedure • and Choreography defines protocol. • Above figure shows this issue, • where in "orchestration" there is a defined flow of processes • that will be executed, • and in "choreography" each WS knows • how it should act when an event comes in. Dr.Withalm

35. Presentation Service Presentation Tier Aggregation Service Aggregation Tier Business Service Business Service Business Logic Tier Data Service Data Tier Aggregation Tier Dr.Withalm

36. Source: 2003 Evolution of Application Deployment Styles Typical Access Via: Web Services B2B Market, Global Enterprise HTTP + XML Service-Oriented Architecture Small Enterprise, Complex Applications Time MOM SOA ComponentHomogeneous Application ORB ObjectProgram CBD OOD Dr.Withalm

37. Wire together to build a small device Put together to build a complex device Service Consumer Back Office Service Archiving Service Print Service Programming Paradigm Programming Paradigm Real World Analogy Object Orientation: Aligned with fine-grained business objects Reuse of source code based on the notion of types Increased maintainability and modifiability of the program code through encapsulation Component Orientation: Aligned with mid-grained business functions Reuse based on prefabricated, executable code Increased maintainability and modifiability of the application through composition Service Orientation: Aligned with coarse-grained business processes Flexibility and extensibility through composition, federation, and orchestration of services Increased interoperability and scalability through loose-coupling It is there and running, simply connect and use. Dr.Withalm Archiving Service

38. Programming Approaches/1Declarative programming • describes only the problem • inference mechanism tries to solve the problem described • provided by the respective program runtime environment • e.g. Prolog Dr.Withalm

39. Programming Approaches/2Event-driven programming • reacts to outside events and takes corresponding action • typical programs developed with this approach include • graphical user interfaces that react to user input • control programs that react to external environmental conditions, e.g. to changes in temperature Dr.Withalm

40. Programming Approaches/3Procedural programming • Represents a sequential algorithm • which is being executed step by step • The execution of the algorithm is governed by data which can also be modified by the algorithm Dr.Withalm

41. Programming Approaches/4Structured programming • Extension of procedural programming • The main problem is broken down into several sub problems • each sub problem is solved • Advantage: considerable simplification of individual algorithms • functions, procedures or modules • The overall program is also easier to maintain and service Dr.Withalm

42. Keeping Investments Small (Changes) Focus is Knowledge Platform Agnostic Architecture Centric More like CM Ongoing Activity Focus is Operation Business Driven Impact – Development / Project Management Dr.Withalm

43. Integrate Orchestrate Deploy Secure Service-Oriented Architecture Develop Analyze Access Manage Dr.Withalm

44. ROI Improvements ROI Services Components Objects Time Dr.Withalm

45. Component Concepts Topics Objects Components Services Standardization Proprietary Proprietary Open Coupling Tight Tight Loose Granularity Fine Fine to Coarse Business relevant Implementation Monolithic Separate Independent Interfaces Defined Formal Contractual Dr.Withalm

46. Componentization ROI Services EAI Custom Time Dr.Withalm

47. Componentization Concepts Topics Custom EAI Services Standardization Proprietary Proprietary Open Separation Application specific Application independent Implementation independent Scope Internal Some external Internal/External Dr.Withalm

48. Scope Events Services Components Methods Subroutines Granularity Evolution of SOA Affinity with Business Models Technical Components Business Components (Source: Gartner) Dr.Withalm

49. Defining ‘Event’ • Ordinary event: Something that happened in the real world. A large or small change in the state of the universe. • Ordinary business event: A meaningful change in the state of the enterprise or of something relevant to the enterprise, such as a customer order, an employee address change, the arrival of a shipment at a loading dock, a bill payment or a truck breakdown. • Software event: A binary record of an ordinary event. Data, often packaged in the form of a message or electronic document, that describes an ordinary event. (Source: Gartner) Dr.Withalm

50. Event-Driven Business Processes • Conventional: Build-to-stock • Event-driven: Build-to-order • Conventional: Static pricing • Event-driven: Yield management through dynamic pricing • Conventional: Periodic reports and ad hoc inquiry • Event-driven: Supply chain monitoring (Source: Gartner) Dr.Withalm