Successfully reported this slideshow.


Published on

  • Be the first to comment

  • Be the first to like this

  1. 1. Service-Oriented Architecture <ul><li>Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well-defined interfaces. </li></ul><ul><li>Loosely coupled: The use of well-defined interfaces to connect services; SOAs are built using a loosely coupled approach, where a change in one service does not require changes in linked services. </li></ul><ul><li>Enterprise service bus: A software infrastructure that uses a standard interface and messaging to integrate applications; one way to implement an SOA. </li></ul>
  2. 2. Problems of Current Client-Server Architecture <ul><ul><li>Problems in combining data: </li></ul></ul><ul><ul><li>Legacy data systems can not be altered to support integration </li></ul></ul><ul><ul><li>Data systems use different terms or meaning of similar terms </li></ul></ul><ul><ul><li>Some data sources, do not have a schema nor formal access methods </li></ul></ul>Result: User Carries the Burden In current client-server architectures the user carries much of the burden of integration. User Tasks: Fi nd servers Reformat data Custom process Server Server Server Client-Server Architecture: User accesses, processes and integrates data by customized tools User
  3. 3. Mediator-Based Integration Architecture (Wiederhold, 1992) <ul><li>Software agents (mediators) can perform many of the data integration chores </li></ul><ul><li>Heterogeneous sources are wrapped by translation software local to global language </li></ul><ul><li>Mediators (web services) obtain data from wrappers or other mediators and pass it on … </li></ul><ul><li>Wrappers remove technical, while mediators resolve the logical heterogeneity </li></ul><ul><li>The job of the mediator is to provide an answer to a user query ( Ullman , 1997 ) </li></ul><ul><li>In database theory sense, a mediator is a view of the data found in one or more sources </li></ul>Busse et. al, 1999 Wrapper Wrapper Service Service Query View Mediators
  4. 4. Service Oriented Architecture <ul><li>Peer-to-peer network representation </li></ul>Data, as well as services and users (of data and services) are distributed Users compose data processing chains form reusable services Intermediate and resulting data are also exposed for possible further use Processing chains can be further linked into value-adding processes Service chain representation User Tasks: Fi nd data and services Compose service chains Expose output User Carries less Burden In service-oriented peer-to peer architecture, the user is aided by software ‘agents’ Control Data Process Process Process Data Service Catalog Process Chain 2 Chain 1 Chain 3 Data Service
  5. 5. Web Programs Built on DataFed Infrastructure
  6. 6. Generic Data Flow and Processing in DATAFED DataView 1 Data Processed Data Portrayed Data Process Data Portrayal/ Render Abstract Data Access View Wrapper Physical Data Abstract Data Physical Data Resides in autonomous servers; accessed by view-specific wrappers which yield abstract data ‘slices’ Abstract Data Abstract data slices are requested by viewers; uniform data are delivered by wrapper services DataView 2 DataView 3 View Data Processed data are delivered to the user as multi-layer views by portrayal and overlay web services Processed Data Data passed through filtering, aggregation, fusion and other web services
  7. 7. Service Chaining in Spatio-Temporal Data Browser Render Spatial Slice Find/Bind Data nDim Data Cube Time Slice Time Portrayal Spatial Portrayal Spatial Overlay Time Overlay OGC-Compliant GIS Services Time-Series Services Portray Overlay Homogenizer Client Browser Cursor/Controller Maintain Data Vector GIS Data XDim Data SQL Table OLAP Satellite Images Data Sources Catalog Wrapper Mediator
  8. 8. An Application Program: Voyager Data Browser <ul><li>The web-program consists of a stable core and adoptive input/output layers </li></ul><ul><li>The core maintains the state and executes the data selection, access and render services </li></ul><ul><li>The adoptive, abstract I/O layers connects the core to evolving web data, flexible displays and to the a configurable user interface: </li></ul><ul><ul><li>Wrappers encapsulate the heterogeneous external data sources and homogenize the access </li></ul></ul><ul><ul><li>Device Drivers translate generic, abstract graphic objects to specific devices and formats </li></ul></ul><ul><ul><li>Ports connect the internal parameters of the program to external controls </li></ul></ul><ul><ul><li>WDSL web service description documents </li></ul></ul>Data Sources Controls Displays I/O Layer Device Drivers Wrappers App State Data Flow Interpreter Core Web Services WSDL Ports
  9. 9. Peer-to-Peer Computing (P2P) or Service-Oriented Architecture (??) <ul><li>P2P is an architectural principle based on decentralization and resource sharing </li></ul><ul><li>It is replacing the current paradigm of client-server computing </li></ul><ul><li>Data are passed directly from peer-to-peer, rather than through ‘data integrator’ servers </li></ul><ul><li>The contribution of database community to P2P is the introduction of schemas </li></ul><ul><li>DATAFED uses the multidimensional data cube as the global schema </li></ul><ul><li>P2P was made popular by Napster; now it is an intense academic research topic </li></ul><ul><li>Music files were all uniformly formatted MP3 files; science data need more descriptors </li></ul><ul><li>Hence the challenge of scientific data sharing – even in P2P environment </li></ul>
  10. 10. Tight and Lose Coupled Programs <ul><li>Coupling is the dependency between interacting systems </li></ul><ul><li>Dependency can be real (the service one consumes) or artificial (language, platform…) </li></ul><ul><li>One can never reduce real dependency but itself is evolving </li></ul><ul><li>One can never get rid of artificial dependency but one can reduce artificial dependency or the cost of artificial dependency. </li></ul><ul><li>Hence, loose coupling describes the state when artificial dependency or the cost of artificial dependency has been reduced to the minimum. </li></ul>They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes... SOA is the right mechanism—a transmission of sorts—for an IT environment in which data-crunching legacy systems must mesh with agile front-facing applications
  11. 11. The pathway to a service-oriented architecture Bob Sutor, IBM <ul><ul><li>IBM identified four steppingstones on the path to SOA nirvana and its full business benefits </li></ul></ul><ul><li>1. Turn applications into Web services for multiple consumers via a middle-tier Web server </li></ul><ul><ul><li>This is an ideal entry point for those wishing to deploy an SOA with existing enterprise applications </li></ul></ul><ul><ul><li>Target customer retention or operational efficiency projects </li></ul></ul><ul><ul><li>Work with multiple consumers to correctly define the granularity of your services </li></ul></ul><ul><ul><li>Pay proper attention to keeping the services and the applications loosely coupled </li></ul></ul><ul><li>2. Choreography of web services </li></ul><ul><ul><li>Create business logic outside the boundaries of any one application </li></ul></ul><ul><ul><li>Make new apps easy to adjust as business conditions or strategy require </li></ul></ul><ul><ul><li>Keep in mind asynchronous services as well as compensation for sequences of actions that don't complete successfully </li></ul></ul><ul><ul><li>Don’t forget managing the processes and services </li></ul></ul><ul><li>3. Leverage existing integration tools </li></ul><ul><ul><li>leverage your existing enterprise messaging software; enterprise messaging and brokers </li></ul></ul><ul><ul><li>Web services give you an easy entry to SOA adoption </li></ul></ul><ul><ul><li>WS are not the gamut of what service orientation means; Modeling is likely required </li></ul></ul><ul><ul><li>Integration with your portal for &quot;people integration&quot; will also probably happen </li></ul></ul><ul><li>4. Be flexible, responsive on-demand business </li></ul><ul><ul><li>Use SOA to gain efficiencies, better use of software and information assets, and competitive differentiation. </li></ul></ul>
  12. 12. <ul><li>The pathway to a service-oriented architecture </li></ul><ul><li>Opinion by Bob Sutor, IBM Bob Sutor is IBM's director of WebSphere Infrastructure Software. DECEMBER 03, 2003 (COMPUTERWORLD) - I recently read through a large collection of analyst reports on service-oriented architecture (SOA) that have been published in the past year. I was pleasantly surprised at the amount of agreement among these industry observers and their generally optimistic outlook for the adoption of this technology. </li></ul><ul><li>SOA is not really new -- by some accounts, it dates back to the mid-1980s -- but it's starting to become practical across enterprise boundaries because of the rise of the Internet as a way of connecting people and companies. Even though the name sounds very technical, it's the big picture behind the use of Web services, the plumbing that's now being used to tie together companies with their customers, suppliers and partners. </li></ul><ul><li>In an SOA world, business tasks are accomplished by executing a series of &quot;services,&quot; jobs that have well-defined ways of talking to them and well-defined ways in which they talk back. It doesn't really matter how a particular service is implemented, as long as it responds in the expected way to your commands and offers the quality of service you require. This means that the service must be secure, reliable and fast enough to meet your needs. This makes SOA a nearly ideal technology to use in an IT environment where software and hardware from multiple vendors is deployed. </li></ul><ul><li>At IBM, we've identified four steppingstones on the path to SOA nirvana and its full business benefits. Unlike most real paths, this is one you can jump on at almost any point </li></ul><ul><li>The first step is to start making individual applications available as Web services to multiple consumers via a middle-tier Web application server. I'm not precluding writing new Web services here, but this is an ideal entry point for those wishing to deploy an SOA with existing Java or Cobol enterprise applications, perhaps targeting customer retention or operational efficiency projects. </li></ul><ul><li>You should work with multiple consumers to correctly define the granularity of your services, and pay proper attention to keeping the services and the applications using them loosely coupled. </li></ul><ul><li>The second step involves having several services that are integrated to accomplish a task or implement a business process. Here you start getting serious about modeling the process and choreographing the flow among the services, both inside and outside your organization, that implement the process. </li></ul><ul><li>The choreography is essentially new business logic that you have created outside the boundaries of any one application, therefore making it easier to adjust as business conditions or strategy require. As part of this, you will likely concern yourself with asynchronous services as well as compensation for sequences of actions that don't complete successfully. Your ability to manage the processes and services and their underlying implementations will start to become important as well. This entry point is really &quot;service-oriented integration&quot; and will probably affect a single department or a business unit such as a call center. </li></ul><ul><li>If you already have an enterprise application integration infrastructure, you will most like enter the SOA adoption path at the third steppingstone. At this point, you are looking to use SOA consistently across your entire organization and want to leverage your existing enterprise messaging software investment. </li></ul><ul><li>I want to stress here that proper SOA design followed by use of enterprise messaging and brokers constitutes a fully valid deployment of SOA. Web services give you an easy entry to SOA adoption, but they don't constitute the gamut of what service orientation means. Modeling is likely required at this level, and integration with your portal for &quot;people integration&quot; will also probably happen here if you didn't already do this at the previous SOA adoption point. </li></ul><ul><li>The final step on the path is the one to which you aspire: being a flexible, responsive on-demand business that uses SOA to gain efficiencies, better use of software and information assets, and competitive differentiation. At this last level, you'll be able to leverage your SOA infrastructure to effectively run, manage and modify your business processes and outsource them should it make business sense to do so. </li></ul><ul><li>You are probably already employing some SOA in your organization today. Accelerating your use of it will help you build, deploy, consume, manage and secure the services and processes that can make you a better and more nimble business. </li></ul>
  13. 13. Don Box , Microsoft <ul><li>When we started working on SOAP in 1998, the goal was to get away from this model of integration by code injection that distributed object technology had embraced . Instead, we wanted an integration model that made as few possible assumptions about the other side of the wire, especially about the technology used to build the other side of the wire. We've come to call this style of integration protocol-based integration or service-orientation . Service-orientation doesn't replace object-orientation - I don't see the industry (or Microsoft) abandoning objects as the primary metaphor for building individual programs. I do see the industry (and Microsoft) moving away from objects as the primary metaphor for integrating and coordinating multiple programs that are developed, deployed and versioned independently, especially across host boundaries.  In the 1990's, we stretched the object metaphor as far as we could, and through communal experience, we found out what the limits are. With Indigo, we're betting on the service metaphor and attempting to make it as accessible as humanly possible to all developers on our platform. How far we can &quot;shrink&quot; the service metaphor remains to be seen. Is it suitable for cross-process work? Absolutely. Will every single CLR type you write be a service in the future? Probably not - at some point you know where your integration points are and want the richer interaction you get with objects. </li></ul>
  14. 14. Project Status, Plans <ul><li>Status </li></ul><ul><li>Plans </li></ul><ul><ul><li>FASNET </li></ul></ul><ul><ul><li>CATT & Tools as services </li></ul></ul><ul><ul><li>SEEDS (architecture) </li></ul></ul>
  15. 15. Web Services: Connect, Communicate, Describe, Discover <ul><li>Enabling Protocols of the Web Services architecture: </li></ul><ul><li>Connect: Extensible Markup Language (XML) is the universal data format that makes connection and data sharing possible. </li></ul><ul><li>Communicate . Simple Object Access Protocol (SOAP) is the new W3C protocol for data communication, e.g. making requests. </li></ul><ul><li>Describe. Web Service Description Language (WSDL) describes the functions, parameters and the returned results from a service </li></ul><ul><li>Discover . Universal Description, Discovery and Integration (UDDI) is a broad W3C effort for locating and understanding web services. </li></ul>
  16. 16. Data Acquisition and Usage Value Chain Virtual Int. Data Monitor Store Data 1 Monitor Store Data 2 Monitor Store Data n Integrated Data 1 Integrated Data 2 Integrated Data n
  17. 17. Mediated Service-Oriented (Peer-to-Peer) Architecture Wrapper Wrapper Service Service Query View Mediators
  18. 18. <ul><li>Note that in distributed systems responsibility is distributed. For NVODS responsibility for </li></ul><ul><li>The data lies with the data providers. </li></ul>Responsibility <ul><li>Data location with the GCMD and NVODS. </li></ul><ul><li>Application packages (Matlab, Ferret, Excel…) with the developers of these packages. (Services??) </li></ul><ul><li>The data access protocol lies with OPeNDAP . </li></ul>
  19. 19. Data Processing in Service Oriented Architecture <ul><li>Data Values </li></ul><ul><ul><li>Immediacy </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><li>Lose Coupling of data </li></ul><ul><li>Open data processing – let competitive approaches deliver the appropriate products to the right place </li></ul>