Malek

409 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
409
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • CS 578 Software Architecture -- Origins of Software Architectures May 6, 2010 © 2001-3 Neno Medvidovic & Edward Colbert
  • CS 578 Software Architecture -- Origins of Software Architectures May 6, 2010 © 2001-3 Neno Medvidovic & Edward Colbert
  • CS 578 Software Architecture -- Origins of Software Architectures May 6, 2010 © 2001-3 Neno Medvidovic & Edward Colbert
  • CS 578 Software Architecture -- Origins of Software Architectures May 6, 2010 © 2001-3 Neno Medvidovic & Edward Colbert
  • CS 578 Software Architecture -- Origins of Software Architectures May 6, 2010 © 2001-3 Neno Medvidovic & Edward Colbert
  • CS 578 Software Architecture -- Architecture Styles May 6, 2010 © 2001-3 Neno Medvidovic & Edward Colbert
  • CS 578 Software Architecture -- Architecture Styles May 6, 2010 © 2001-3 Neno Medvidovic & Edward Colbert
  • Malek

    1. 1. Sam Malek SOA Research Issues Jan., 22, 2009
    2. 2. Outline <ul><li>Service-Oriented Architecture </li></ul><ul><ul><li>Software Architecture </li></ul></ul><ul><ul><li>Architectural Style </li></ul></ul><ul><ul><li>Service </li></ul></ul><ul><li>Realizing SOA </li></ul><ul><ul><li>Web Services </li></ul></ul><ul><li>Research Challenges </li></ul>
    3. 3. What is Service-Oriented Architecture? <ul><li>Service-Oriented Architecture (SOA) is an architectural style . Applications built using an SOA style deliver functionality as services that can be used or reused when building applications. </li></ul>
    4. 4. Software Architecture Definition <ul><li>Definition. A software system’s architecture is the set of principal design decisions about the system. </li></ul><ul><li>Software architecture is the blueprint for a software system’s construction and evolution. </li></ul>
    5. 5. Why Software Architecture?
    6. 6. Why Software Architecture?
    7. 7. What should be in software architecture? <ul><li>“ Principal design decisions” </li></ul><ul><li>“ Principle” implies a degree of importance that grants a design decision “architectural status” </li></ul><ul><li>It also implies that not all design decisions are architectural, that is, they do not necessarily impact a system’s key characteristics </li></ul><ul><li>How one defines “principal” will depend on what the stakeholders define as the system goals </li></ul>
    8. 8. Software Architecture’s Elements <ul><li>A software system’s architecture typically is not (and should not be) a uniform monolith </li></ul><ul><li>A software system’s architecture should be a composition and interplay of different elements </li></ul><ul><ul><li>Processing </li></ul></ul><ul><ul><li>Data, also referred as information or state </li></ul></ul><ul><ul><li>Interaction </li></ul></ul>
    9. 9. Component <ul><li>Elements that encapsulate processing and data in a system’s architecture are referred to as software components . </li></ul><ul><li>Definition . A software component is an architectural building block that encapsulates a subset of the system’s functionality and/or data, and restricts access to them via an explicitly defined interface. </li></ul>
    10. 10. Connector <ul><li>In complex systems interaction might become more important and challenging than the functionality of the individual components. </li></ul><ul><li>Definition . A software connector is an architectural building block tasked with regulating interactions among components. </li></ul><ul><li>In traditional, desktop software systems, connectors would have usually manifested themselves as simple procedure calls or shared data accesses. </li></ul>
    11. 11. Example of a Software Architecture
    12. 12. Architectural Style <ul><li>An architectural style is a named set of constraints (e.g., rules) you put on your development </li></ul><ul><ul><li>Constraints may be topological, behavioral, communication-oriented, you name it </li></ul></ul>VS.
    13. 13. Race Car vs. SUV
    14. 14. Race Car vs. SUV
    15. 15. Basic Properties of Styles <ul><li>A vocabulary of design elements </li></ul><ul><ul><li>In civil engineering we have: mortar, brick, column, concrete, … </li></ul></ul><ul><ul><li>We want to have the same in software: pipes, filters, objects, servers, clients, publication, notification, advertisement, … </li></ul></ul><ul><li>A set of configuration rules </li></ul><ul><ul><li>Topological constraints that determine allowed compositions of elements </li></ul></ul><ul><li>A semantic interpretation </li></ul><ul><ul><li>Compositions of design elements have well-defined meanings </li></ul></ul><ul><ul><li>Brick structure vs. concrete structure vs. wood structure vs. … </li></ul></ul><ul><ul><li>Client-server vs. peer-to-peer vs. publish-subscribe vs. C2 vs. … </li></ul></ul>
    16. 16. Client-Server vs. C2
    17. 17. What is a Service (Merriam-Webster Dic.) <ul><li>A facility supplying some public demand </li></ul><ul><li>the work performed by one that serves HELP , USE , BENEFIT </li></ul>
    18. 18. What is a Service? <ul><li>A service is a reusable component that can be used as a building block to form larger, more complex applications </li></ul><ul><li>A service may be as simple as “get me some person’s name” or as complex as “process a purchase” </li></ul>
    19. 19. services become first class suppliers register their capabilities, consumers look for services not specific components <ul><li>suppliers are developed with no knowledge about which and how many components will consume their services </li></ul>c 2 c 1 invokes requests consumes provides supplies service client user agent consumer server “ service” component provider supplier
    20. 20. two models for activating service supply: factory & pool server 1: supplier factory c 2 c 1 create instance service request middleware glue code server 2: supplier pool c 3 middleware glue code c 3 c 3
    21. 21. stateful suppliers keep state of conversation, stateless don’t server 1: supplier factory c 2 c 1 create instance service request access state middleware glue code server 2: supplier pool c 3 c 3 c 3 r 1 r 2 r 1 , r 2 c 1 :r 1 , r 2 c 1 ’: r 1 ’ c 1 ”: r 1 ”, r 2 ”, r 3 ” middleware glue code r 1 r 2 example: EJB entity beans and session beans
    22. 22. SOA Style
    23. 23. Outline <ul><li>Service-Oriented Architecture </li></ul><ul><ul><li>Software Architecture </li></ul></ul><ul><ul><li>Architectural Style </li></ul></ul><ul><ul><li>Service </li></ul></ul><ul><li>Realizing SOA </li></ul><ul><ul><li>Web Services </li></ul></ul><ul><li>Research Challenges </li></ul>
    24. 24. CORBA defines interfaces , not implementations, to shield apps from heterogeneity of language, OS, hardware… <ul><li>an implementation of CORBA manages: </li></ul><ul><li>object location </li></ul><ul><li>connection & memory management </li></ul><ul><li>parameter marshaling </li></ul><ul><li>event & request delivery </li></ul><ul><li>error handling & fault tolerance </li></ul><ul><li>object/server activation </li></ul><ul><li>concurrency & synchronization </li></ul><ul><li>security </li></ul>credits: Douglas C. Schmidt
    25. 25. J2EE defines specific infrastructure (containers) and communication mechanisms (JMS, RMI)
    26. 26. Middleware solutions for SOA have significant challenges <ul><li>too many “standards” one born every few months: code evolution nightmare </li></ul><ul><li>integration with legacy systems millions of LOC and billions of $ already invested </li></ul><ul><ul><li>strategy: wrappers around old code </li></ul></ul><ul><li>with wrappers latency becomes an issue </li></ul>
    27. 27. middleware may alleviate dependency on programming language and OS but … introduces dependency on middleware <ul><li>suppose that your company decided to use J2EE & JMS to integrate applications </li></ul><ul><li>now your company is about to merge with another that used (RPC-based) CORBA to integrate their apps </li></ul><ul><li>and business is pressing towards buying a 3 rd party product that uses DCOM </li></ul>how do you integrate all of that?
    28. 28. web services come in as an integration technology <ul><li>focus on bridging existing technologies middleware for middleware </li></ul><ul><ul><li>it’s about how to access an application, it is not an implementation technology </li></ul></ul><ul><li>looser coupling than RPC-based middleware </li></ul><ul><ul><li>avoid proprietary APIs </li></ul></ul><ul><ul><li>Simple Object Access Protocol (SOAP) based on sending XML messages over http, no SOAP API or ORB </li></ul></ul><ul><li>wider industrial support than previous middleware </li></ul><ul><ul><li>Microsoft’s .net, IBM’s Webshpere, Sun’s J2EE </li></ul></ul>
    29. 29. web services introduces its own set of standards service description messages directory data data types … and: UDDI universal description, discovery and integration WSDL web services description language SOAP simple object access protocol XML Schema XML eXtensible markup language which work on top of:
    30. 30. multiple proposals for service composition and coordination <ul><li>Business Process Execution Language BPEL </li></ul><ul><li>Web Services Conversation Language WSCL </li></ul><ul><li>Web Services Coordination WS-C </li></ul><ul><li>Web Services Transaction WS-Tx </li></ul>credits: Frank Leymann, Kai Guentzel SOAP RPC
    31. 31. the W3C is actively working on the definition of the W eb S ervice D escription L anguage (v 2.0) <description namespace = “http/… “> < types > xschema types </types> < interface > ways to access the service </interface> < binding > communication protocols </binding> < service > a list of interfaces and bindings </service> </description > structure of a service description: let’s take a quick look at each of these
    32. 32. namespaces disambiguate identifiers <description namespace = “http/… “> <types> … </types> <interface> … </interface> <binding> … </binding> <service> … </service> </description > <description xmlns=&quot;http://www.w3.org//01/wsdl&quot; targetNamespace= &quot;http://greath.example.com/2004/wsdl/resSvc&quot; xmlns:tns= &quot;http://greath.example.com/2004/wsdl/resSvc&quot; xmlns:ghns = &quot;http://greath.example.com/2004/schemas/resSvc&quot; xmlns:wsoap= &quot;http://www.w3.org//01/wsdl/soap&quot; xmlns:soap=&quot;http://www.w3.org/2003/05/soap-envelope&quot; xmlns:wsdlx= &quot;http://www.w3.org//01/wsdl-extensions&quot;> …
    33. 33. types are defined using XML schema or DTDs <description namespace = “http/… “> <types> … </types> <interface> … </interface> <binding> … </binding> <service> … </service> </description > <types> <xs:schema xmlns:xs=&quot;http://www.w3.org/2001/XMLSchema&quot; targetNamespace=&quot;http://greath.example.com/2004/schemas/resSvc&quot; xmlns=&quot;http://greath.example.com/2004/schemas/resSvc&quot;> <xs:element name=&quot;checkAvailability&quot; type=&quot;tCheckAvailability&quot;/> <xs:complexType name=&quot;tCheckAvailability&quot;> <xs:sequence> <xs:element name=&quot;checkInDate&quot; type=&quot;xs:date&quot;/> <xs:element name=&quot;checkOutDate&quot; type=&quot;xs:date&quot;/> <xs:element name=&quot;roomType&quot; type=&quot;xs:string&quot;/> </xs:sequence> </xs:complexType> …
    34. 34. interfaces support operations with in and out parameters < interface name = &quot;reservationInterface&quot; > <fault name = &quot;invalidDataFault&quot; element = &quot;ghns:invalidDataError&quot;/> < operation name=&quot;opCheckAvailability&quot; pattern=&quot;http://www.w3.org//01/wsdl/in-out&quot; style=&quot;http://www.w3.org//01/wsdl/style/iri&quot; wsdlx:safe = &quot;true&quot;> < input messageLabel=&quot;In&quot; element=&quot;ghns:checkAvailability&quot; /> < output messageLabel=&quot;Out&quot; element=&quot;ghns:checkAvailabilityResponse&quot; /> <outfault ref=&quot;tns:invalidDataFault&quot; messageLabel=&quot;Out&quot;/> </operation> <description namespace = “http/… “> <types> … </types> <interface> … </interface> <binding> … </binding> <service> … </service> </description >
    35. 35. different communication patterns are supported <ul><li>in-only: receives a message but will not respond </li></ul><ul><li>robust in-only: receives a message and may issue a fault message </li></ul><ul><li>in-out: receives a message and may issue a reply or fault message </li></ul><ul><li>… eight patterns defined, but open to more some are just the symmetric, e.g., out-in </li></ul><description namespace = “http/… “> <types> … </types> <interface> … </interface> <binding> … </binding> <service> … </service> </description > <operation name=&quot;opCheckAvailability&quot; pattern=&quot;http://www.w3.org//01/wsdl/in-out&quot; style=&quot;http://www.w3.org//01/wsdl/style/iri&quot; wsdlx:safe = &quot;true&quot;> …
    36. 36. binding defines the communication protocol typically SOAP < binding name=&quot;reservationSOAPBinding&quot; interface=&quot;tns:reservationInterface&quot; type=&quot;http://www.w3.org//01/wsdl/soap&quot; wsoap:protocol =&quot;http://www.w3.org/2003/05/soap/bindings/HTTP&quot;> <fault ref=&quot;tns:invalidDataFault&quot; wsoap:code=&quot;soap:Sender&quot;/> <operation ref=&quot;tns:opCheckAvailability&quot; wsoap:mep=&quot;http://www.w3.org/2003/05/soap/mep/soap-response&quot;/> </binding> <description namespace = “http/… “> <types> … </types> <interface> … </interface> <binding> … </binding> <service> … </service> </description >
    37. 37. service associates the interfaces with a URL and protocol (binding) < service name=&quot;reservationService&quot; interface =&quot;tns:reservationInterface&quot;> <endpoint name=&quot;reservationEndpoint&quot; binding =&quot;tns:reservationSOAPBinding&quot; address =&quot;http://greath.example.com/2004/reservation&quot;/> </service> <description namespace = “http/… “> <types> … </types> <interface> … </interface> <binding> … </binding> <service> … </service> </description >
    38. 38. WS descriptions may be posted on UBRs UDDI Business Registry Service Type Registrations SW companies, standards bodies, and programmers populate the registry with descriptions of different types of services 1 . Business Registrations credits: Tevfik Bultan 3 . UBR assigns a programmatically unique identifier to each service and business registration Marketplaces, search engines, and business apps query the registry to discover services at other companies 4 . Businesses populate the registry with descriptions of the services they support 2 . Business uses this data to facilitate easier integration with each other over the Web 5 .
    39. 39. a UDDI Business Registry supports business registrations <ul><li>XML document </li></ul><ul><li>created by supplier company (or on its behalf) </li></ul><ul><li>may have multiple service listings </li></ul>credits: Tevfik Bultan businessEntity businessKey name URL description contacts businessServices identifierBag categoryBag Phone Address Email Contact businessService Key Name Description BindingTemplates Phone Address Email Contact businessService serviceKey tModelKey Name Description BindingTemplates keyedReference tModelKey keyName keyValue keyedReference tModelKey keyName keyValue keyedReference tModelKey keyName keyValue keyedReference tModelKey keyName keyValue
    40. 40. service type registrations in UDDI define a signature (tModelKey) and are meant to be interpreted by programmers … service descriptions may or may not be WSDL businessEntity TB993… Harbour Metals www.harbourmetals.co.au “ Serving Inner Sydney Harbour for … contacts businessServices identifierBag categoryBag 872-6891 4281 King’s Blvd, Sydney, NSW [email_address] Peter Smythe businessService Key Name Description BindingTemplates businessService 23T701e54683nf… Online catalog “ Website where you can … BindingTemplates BindingTemplate 5E2D412E5-44EE-… http://www.sydneynet/harbour… tModelInstanceDetails tModelInstanceInfo 4453D6FC-223C-3ED0… http://www.rosetta.net/catalogPIP keyedReference DFE-2B… DUNS 45231 keyedReference EE123… NAICS 02417 tModelKeys
    41. 41. Outline <ul><li>Service-Oriented Architecture </li></ul><ul><ul><li>Software Architecture </li></ul></ul><ul><ul><li>Architectural Style </li></ul></ul><ul><ul><li>Service </li></ul></ul><ul><li>Realizing SOA </li></ul><ul><ul><li>Web Services </li></ul></ul><ul><li>Research Challenges </li></ul>
    42. 42. SOC Research Road Map
    43. 43. Research Challenges <ul><li>Foundation </li></ul><ul><ul><li>Dynamically reconfigurable runtime architectures </li></ul></ul><ul><ul><li>End-to-end security solutions </li></ul></ul><ul><ul><li>Semantically enhanced service discovery </li></ul></ul><ul><li>Composition </li></ul><ul><ul><li>Dynamic and adaptive processes </li></ul></ul><ul><ul><li>QoS-aware service composition </li></ul></ul>
    44. 44. Research Challenges <ul><li>Management and Monitoring </li></ul><ul><ul><li>Self-configuring, self-adapting, self-healing, self-optimizing, self-protecting management services </li></ul></ul><ul><li>Design and Development </li></ul><ul><ul><li>Engineering of service apps </li></ul></ul><ul><ul><li>Service versioning and adaptivity </li></ul></ul><ul><ul><li>Service governance </li></ul></ul>
    45. 45. Topics Covered in This Course <ul><li>Software Architecture </li></ul><ul><li>Autonomic Computing </li></ul><ul><li>Coordination </li></ul><ul><li>Modeling </li></ul><ul><li>Service Discovery and Selection </li></ul><ul><li>Quality of Service and Analysis </li></ul><ul><li>Monitoring </li></ul><ul><li>Service Composition </li></ul>

    ×