Service-oriented Architectures Veli Biçer


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Monolithic applications are applications where the code that implements the business rules, data access, and user interface are all tightly coupled together as part of a single, large computer program. A monolithic application is typically deployed on a single platform, often a mainframe or midrange computer. There are, however, examples of monolithic applications running on smaller systems - or even distributed across multiple machines. The determining characteristic of a monolithic application is that the code is tightly coupled and highly interdependent. Object-orientation divides the application into the units of the logic based on the functionality and data. In a 2-tier model, the desktop user connects directly to a database. All processing is done in the client application—the database serves only as a repository for data. Then the tiered applications came into play. Here we include a middle layer for the application logic. This middle layer can also be multiplied to constitute the n-tiers. The web sites actually falls into this category. The thin clients , I mean the browsers, and the Web sites actually falls into this category. You have browsers, an application server hosting the logic and the database.
  • In further cases, the objects are distributed in the environment. Actually this gain attention with the introduction of the Wide Area Networks and the Internet. Remote Method invocations actually falls into this category. After that the component orientation came into play. Here we see the concept component which … Ali Hocanin Dokumana Bak Service : Capabilities performed by one for another to achieve a desired outcome Orientation : Functionally aligning architecture to enable a collection of independent services to be linked together to solve a business problem Architecture : The fundamental organization of a system embodied in its capabilities, their interactions, and the environment
  • The core of the SOA involves the Services. I will mention what a service is in a few slides soon. Loose Coupling. Changing in time. Can be implemented in different platforms and with different technologies. Each service should be described. The description defines the service and the requirements you have to have to use that service. In ws world, this is achieved through WSDL. In addition, Policies are also important to specify the requirements such as security. Once the description is achieved services are published, discovered, selected and binded. The discovery phase achieves this through registries. The service registries such as ebXML, UDDI, which will be mentioned soon, currently achieves discovery syntatically. It is mostly supported with taxonomies. However, fully automated discovery, the current trend is to use the ontologies such as WSMO approach. One thing to note in SOA is that it is fully message oriented. Therefore, there has to be mechanism to achieve the
  • According to the Business Rules Group [10], “a business rule is a statement that defines and constraints some business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules which concern the project are atomic, that is, they cannot be broken down further.” Modeling business rules as separate entities offers great flexibility. Especially in the e-commerce domain, this can be a valuable advantage, since the business analyst, who ideally authors the business rules, does not need to have programming knowledge to change the rules. Typically, changing the business rules happens more often than changing the large e-commerce applications. Moreover, extracting the business rules from the business logic leads to a better decoupling of the system, which, as a consequence, increases maintainability. One of the most important facts about business rules is that they are declarative statements, they specify what has to be done and not how .
  • Unlike Object Oriented Programming paradigms, where the focus is on packaging data with operations, the central focus of Service Oriented Architecture is the task or business function getting something done.
  • Service : A mechanism to enable access to one or more capabilities using a prescribed interface and consistent with constraints and policies as specified by the service description. Visibility is the relationship between service participants that is satisfied when they are able to interact with each other Awareness: Service description, Discovery Willingness: Policy & contract Reachability: Communication Interacting with a service involves performing actions against the service Behaviour Model , Information Model : The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter. The real world effect is couched in terms of changes to the state shared by the participants and stakeholders in a service interaction Policy : Constraint representing the intention of a participant in a service Contract : Constraint representing an agreement between two or more participants. The service description represents the information needed in order to use, manage or provide a service. The execution context is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities Actually this reference model can be regarded as an ontology if extended. Currently it is in the draft version but can be used as a tool for discovery. The process is ongoing…
  • SCA provides an assembly model to simplify and standardize the development of the services for SOA. This is achieved by using a series of the artifacts referenced by an XML File. The control file provides the associations to the related documents to implement a service. The pragmas on the other hand achieves the same functionality through inline comments. The interfaces provide the external view of the service. Such as WSDL The implementation relates the service to an implementation such as Java, .NET or BPEL Policy specifications for the container to configure itself. The services required Support for WS-ResourceFramework. Not going into details. The specification of the valid sequence of the invocation of the methods the service provide. This is machine readable syntax. For example, for healthcare domain, a modifyLabOrder method must follow createLabOrder method but not be later than the submitLabOrder method.
  • Module: Largest composition of tightly-coupled components developed and deployed together Basic unit of loosely-coupled composition Includes components, external services, entry points, wires Components: Instances of implementations Configurable aspects of a component are defined as Component Type Component Type: Specifies the interfaces component provides The other component interfaces that the service references Properties that can be set to configure component Component Implementation: Default implementation types are Java, BPEL, C++… Provides an extension mechanism Referenced by components Interfaces: Referenced by component types, components… Java, WSDL 1.1/2.0
  • Client : Objectives that a client wants to achieve by using Web Services Web Services : Semantic description of Web Services: Capability (functional) Interfaces (usage) Mediators : Connectors between components with mediation facilities for handling heterogeneities Ontologies : Provide the formally specified terminology of the information used by all other components
  • Define the requirements Decompose the system Identify the business processes Identify the rules Identify the services Implementation
  • Service-oriented Architectures Veli Biçer

    1. 1. Service-oriented Architectures Veli Bi ç er
    2. 2. Agenda <ul><li>What is SOA? </li></ul><ul><li>Main Concepts </li></ul><ul><li>OASIS SOA Reference Model </li></ul><ul><li>Open Service Oriented Architecture </li></ul><ul><li>Web Services </li></ul><ul><li>WS-BPEL </li></ul><ul><li>Choreography </li></ul><ul><li>Service Oriented Analysis & Design </li></ul><ul><li>A few words from SODSL </li></ul>
    3. 3. What is SOA ? <ul><li>“ A paradigm for organizing and utilizing distributed capabilities that may be under control of different ownership domains.” OASIS RM for SOA </li></ul><ul><li>“ A form of distributed systems architecture characterized by service abstraction, message orientation, description orientation, and platform neutrality” W3C Web Services Architect. </li></ul><ul><li>“ an evolution of the Component Based Architecture, Interface Based Design (Object Oriented) and Distributed Systems such as DCOM, CORBA, J2EE and the Internet in general” Adobe Systems </li></ul>
    4. 4. What is SOA ? <ul><li>Application Architectures: </li></ul><ul><ul><li>Monolithic Application </li></ul></ul><ul><ul><li>Object-Oriented Application </li></ul></ul><ul><ul><li>Client-Server </li></ul></ul><ul><ul><li>3-tier, n-tier </li></ul></ul><ul><ul><li>Distributed Objects </li></ul></ul><ul><ul><li>Component Orientation </li></ul></ul><ul><ul><li>Service Orientation </li></ul></ul>
    5. 5. What is SOA ? Security Trans. & Reliabil. Discovery Description Choreography Business Rules Applications Services Composition Mediation
    6. 6. What is SOA ? SaaS Business Processes Application Logic (Server) Application Logic (Client) UI Mobile Client HIS RIS/ PACS Billing EMR LIS Internet National ID Management Electronic Claim Processing Internet Internet Mashup Services I P Archetype Repository
    7. 8. What is SOA ?
    8. 9. Main Concepts <ul><li>Service </li></ul><ul><ul><li>A service is a contractually defined behavior that can be implemented and provided by a component for use by another component. </li></ul></ul><ul><ul><li>The mechanism by which needs and capabilities are brought together </li></ul></ul><ul><ul><li>Well-defined, self-contained modules that provide standard business functionality and independent of the state or context of other services </li></ul></ul>
    9. 10. Main Concepts <ul><li>Service Description </li></ul><ul><ul><li>consists of the technical parameters, constraints and policies that define the terms to invoke the service. </li></ul></ul><ul><ul><li>Contains information necessary to interact with the service </li></ul></ul><ul><ul><li>The concept of visibility </li></ul></ul><ul><ul><li>W3C’s Web Service Description Language </li></ul></ul><ul><ul><li>ebXML Collaboration Protocol Profile </li></ul></ul><ul><ul><li>OWL-S Semantic Markup for Web Services </li></ul></ul><ul><ul><li>Web Service Modeling Ontology (WSMO) </li></ul></ul><ul><ul><li>WS-Policy </li></ul></ul>
    10. 11. Main Concepts <ul><li>Advertising </li></ul><ul><ul><li>Pull methodology : potential service consumers request the service provider to send them the service description. </li></ul></ul><ul><ul><li>Push methodology : the service provider, or its agent, sends the service description to potential service consumers. </li></ul></ul><ul><li>Discovery </li></ul><ul><ul><li>A potential consumer obtains information about the existence of a service, its applicable parameters and terms. </li></ul></ul>
    11. 12. Main Concepts <ul><li>Registry/Repository </li></ul><ul><ul><li>A component where users can store and manage artifacts required for their enterprise to function. </li></ul></ul><ul><ul><li>I ncludes artifacts that require sharing among more than one user (such as XML schemas and web-service descriptions) </li></ul></ul><ul><ul><li>OASIS ebXML Registry/Repository </li></ul></ul><ul><ul><li>OASIS Universal Description and Discovery Interface (UDDI) </li></ul></ul>
    12. 13. Main Concepts
    13. 14. OASIS SOA Reference Model <ul><li>D efine the essence of service oriented architecture </li></ul><ul><li>To create a vocabulary and a common understanding of SOA </li></ul><ul><li>Based on concepts present in all SOA’s </li></ul><ul><li>A Reference Model defines SOA in an abstract sense. Example: </li></ul><ul><ul><ul><li>Abstract = Service Description </li></ul></ul></ul><ul><ul><ul><li>Concrete = WSDL </li></ul></ul></ul>
    14. 15. OASIS SOA Reference Model
    15. 16. Open Service Oriented Architecture (OSOA) <ul><li>alliance of industry leaders that share a common interest ( </li></ul><ul><ul><li>defining a language-neutral programming model that exploits SOA characteristics and benefits. </li></ul></ul>
    16. 17. Open Service Oriented Architecture (OSOA)
    17. 18. Service Component Architecture (SCA) <ul><li>Provides an assembly model for services </li></ul><ul><li>To simplify and standardize development </li></ul><ul><li>Control Files or pragmas </li></ul><ul><li>Six values that define a service: </li></ul><ul><ul><li>Interfaces </li></ul></ul><ul><ul><li>Implementation </li></ul></ul><ul><ul><li>Policy Assertion </li></ul></ul><ul><ul><li>Required Interfaces </li></ul></ul><ul><ul><li>Resources </li></ul></ul><ul><ul><li>Valid Operation Sequences </li></ul></ul>
    18. 19. Service Component Architecture (SCA)
    19. 20. Service Component Architecture (SCA) <ul><li>Modules </li></ul><ul><li>Components and Component Types </li></ul><ul><li>Component Implementation: </li></ul><ul><li>Interfaces </li></ul>
    20. 21. Service Component Architecture (SCA)
    21. 22. Service Component Architecture (SCA) <ul><li>ComponentType </li></ul>
    22. 24. Service Component Architecture (SCA)
    23. 25. <ul><li>Apache Tuscany </li></ul><ul><ul><li> </li></ul></ul><ul><li>Eclipse SOA Tools Platform Project </li></ul><ul><ul><li> </li></ul></ul><ul><li>IBM DeveloperWorks SCA </li></ul><ul><ul><li> developerworks/library/specification/ws-sca/ </li></ul></ul>Service Component Architecture (SCA)
    24. 26. Web Services <ul><li>Web Services Technology Stack </li></ul>Transport (HTTP, HTTPS, SMTP,FTP) Messaging(XML,XSD,SOAP,SOAPAttachment) Description&Discovery(WSDL,WS-Policy,UDDI,ebXML) QualityOfService(WS-Security,WS-ReliableMessaging, WS-Addressing,WS-Transaction) Enterprise(WS-BPEL,WS-Management) Mediation(WSMO,ESB,Biztalk) Choreography(WS-BPL,ebBP)
    25. 27. Web Services
    26. 28. WS-BPEL <ul><li>Web Services Business Process Execution Language </li></ul><ul><li>a notation for specifying business process behavior based on web services </li></ul><ul><li>Owned by OASIS, originally created by IBM and Microsoft </li></ul>
    27. 29. WS-BPEL <ul><li>BPEL Constructs: </li></ul><ul><ul><li>sequence: executes one or more activities sequentially. </li></ul></ul><ul><ul><li>flow: executes one or more activities in parallel. </li></ul></ul><ul><ul><li>switch: executes one of several paths based on the value of a condition. </li></ul></ul><ul><ul><li>while: executes a specified activity as long as a condition is true. </li></ul></ul><ul><ul><li>invoke: calls a web service. </li></ul></ul><ul><ul><li>receive: receives an incoming web services call. </li></ul></ul><ul><ul><li>reply: sends a response to a received web services call. </li></ul></ul><ul><ul><li>variables: defines any global variables the process uses. </li></ul></ul><ul><ul><li>assign: allows copying and manipulating data using XPath </li></ul></ul><ul><ul><li>partnerLink: specifying the roles and message exchanges between communication partners </li></ul></ul>
    28. 30. Choreography <ul><li>Describe collaborations of parties by defining from a global viewpoint their common and complementary observable behavior </li></ul><ul><ul><li>I nformation exchanges, the jointly agreed ordering rules … </li></ul></ul><ul><li>Unlike processes, more than one party is included </li></ul><ul><li>More like a global contract which can be realized by more than one parties </li></ul><ul><li>W3C’s Web Services Choreography Description Language (WS-CDL) </li></ul><ul><li>ebXML Business Processes (ebBP) </li></ul>
    29. 31. Place Lab Order Check Insurance Confirmed Order Result Cardiology Hospital X Laboratory Hospital Y Insurance Company
    30. 32. Choreography <ul><li>“ Collaborative Business Process Support in IHE XDS through ebXML Business Processes” ICDE2006 </li></ul>HIS HIS RIS,LIS
    31. 33. Choreography
    32. 34. Enterprise Service Bus <ul><li>A point-to-point Web service may offer significant value: </li></ul>
    33. 35. Enterprise Service Bus <ul><li>What if we have more than one client: </li></ul><ul><ul><li>We need something to simplify this </li></ul></ul>
    34. 36. Enterprise Service Bus <ul><li>Enterprise Service Bus route messages between WSs: </li></ul>
    35. 37. Enterprise Service Bus
    36. 38. Enterprise Service Bus <ul><li>A BPEL Server can be a basic ESB </li></ul><ul><li>But introducing following limitations: </li></ul><ul><ul><li>A process defined using BPEL will commonly need to access local objects </li></ul></ul><ul><ul><li>A process often needs to communicate with other software outside its own environment. </li></ul></ul><ul><ul><li>Processes commonly need to access data </li></ul></ul><ul><ul><li>Business processes commonly involve people </li></ul></ul>
    37. 39. Enterprise Service Bus
    38. 40. WSMO <ul><li>Providing a standard for describing semantic web services. </li></ul><ul><li>Stands for the Web Service Modeling Ontology </li></ul><ul><li> </li></ul><ul><li>WSMO Working Group </li></ul><ul><ul><li>79 Members </li></ul></ul>
    39. 41. WSMO WSMO WG WSMX WG WSML WG A Conceptual Model for SWS A Formal Language for WSMO A Rule-based Language for SW An Execution Environment for WSMO
    40. 42. WSMO
    41. 43. WSMO Mediation Example
    42. 44. Service Oriented Analysis & Design <ul><li>IT Lifecycle proposed by IBM </li></ul>
    43. 45. Service Oriented Analysis & Design <ul><li>“ The wrong approach is to look at the silos, identify interesting data and plant a service on it. The right direction is to lay out the scenarios you want to carry out, and see where they touch silos. A point of tangency is where there might be an opportunity for a service. Services should not be driven bottom up from technology, as DHS folks are proposing, but rather from the top down—with the use cases.” </li></ul><ul><li>Grady Booch on an interview about SOA </li></ul><ul><li> </li></ul>“ This is not to say SOA is a bad thing. Like any technology, you have to approach it in meaningful ways. SOA is very useful for gluing systems together, but it does not address the internal architectures of systems”
    44. 46. A few words from SODSL <ul><li>Framework Completion </li></ul>
    45. 47. A few words from SODSL Ontology Ontology Parser Reasoning Engine Rule Engine Domain Analysis Feature Model Feature Classification Feature Modularization Feature Constraints Domain Design Partitioning Strategy Coordination Model COSEML SOA (WSMO) Domain Implementation SODSL SODSL Generator Process Generator Services
    46. 48. A few words from SODSL Platform Service Process Rules Code Generation COSEML & DSL Feature Model
    47. 49. A few words from SODSL <ul><li>Traditional  Function Oriented </li></ul><ul><li>Object Orientation  Data Oriented </li></ul><ul><li>Component Orientation  Structure Oriented </li></ul><ul><li>Service Orientation  Process Oriented </li></ul><ul><li>Build for change </li></ul><ul><li>Message Oriented, Loosely Coupled </li></ul><ul><li>Rule based </li></ul>
    48. 50. Thank you for your attention… <ul><li>Questions? </li></ul>