Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well-defined interfaces. 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. Enterprise service bus: A software infrastructure that uses a standard interface and messaging to integrate applications; one way to implem
Service-Oriented Architecture
Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well-defined interfaces. 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. Enterprise service bus: A software infrastructure that uses a standard interface and messaging to integrate applications; one way to implement an SOA.
1
Problems of Current Client-Server Architecture
User Tasks: Find servers Reformat data Custom process Server Server Server Client-Server Architecture: User accesses, processes and integrates data by customized tools User Problems in combining data: Legacy data systems can not be altered to support integration Data systems use different terms or meaning of similar terms Some data sources, do not have a schema nor formal access methods Result: User Carries the Burden In current client-server architectures the user carries much of the burden of integration.
2
Software agents (mediators) can perform many of the data integration chores Heterogeneous sources are wrapped by translation software local to global language Mediators (web services) obtain data from wrappers or other mediators and pass it on … Wrappers remove technical, while mediators resolve the logical heterogeneity The job of the mediator is to provide an answer to a user query (Ullman, 1997) In database theory sense, a mediator is a view of the data found in one or more sources Busse et. al, 1999 Wrapper Wrapper Service Service Query View Mediators
3
Service Oriented Architecture
Control Data Process Process Process Peer-to-peer network representation Data Service Catalog Process 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: Find data and services Compose service chains Expose output Chain 2 Chain 1 Chain 3 Data Service User Carries less Burden In service-oriented peer-to peer architecture, the user is aided by software ‘agents’
4
Web Programs Built on DataFed Infrastructure
5
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
6
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 Catalog Wrapper Mediator Client Browser Cursor/Controller Maintain Data Vector GIS Data XDim Data SQL Table OLAP Satellite Images Data Sources
7
An Application Program: Voyager Data Browser
The web-program consists of a stable core and adoptive input/output layers The core maintains the state and executes the data selection, access and render services The adoptive, abstract I/O layers connects the core to evolving web data, flexible displays and to the a configurable user interface: Wrappers encapsulate the heterogeneous external data sources and homogenize the access Device Drivers translate generic, abstract graphic objects to specific devices and formats Ports connect the internal parameters of the program to external controls WDSL web service description documents Data Sources Controls Displays I/O Layer Device Drivers Wrappers App State Data Flow Interpreter Core Web Services WSDL Ports
8
Peer-to-Peer Computing (P2P) or Service-Oriented Architecture (??)
P2P is an architectural principle based on decentralization and resource sharing It is replacing the current paradigm of client-server computing Data are passed directly from peer-to-peer, rather than through ‘data integrator’ servers The contribution of database community to P2P is the introduction of schemas DATAFED uses the multidimensional data cube as the global schema P2P was made popular by Napster; now it is an intense academic research topic Music files were all uniformly formatted MP3 files; science data need more descriptors Hence the challenge of scientific data sharing – even in P2P environment
9
Tight and Lose Coupled Programs
Coupling is the dependency between interacting systems Dependency can be real (the service one consumes) or artificial (language, platform…) One can never reduce real dependency but itself is evolving One can never get rid of artificial dependency but one can reduce artificial dependency or the cost of artificial dependency. Hence, loose coupling describes the state when artificial dependency or the cost of artificial dependency has been reduced to the minimum. 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
10
The pathway to a service-oriented architecture Bob Sutor, IBM
In an SOA world, business tasks are accomplished by executing a series of "services," Services have well-defined ways of talking to them and well-defined ways in which they talk back It doesn't really matter how a service is implemented, as long as it properly responds and offers the quality of service The service must be secure, reliable and fast enough SOA a suitable technology to use in an IT environment where software and hardware from multiple vendors is deployed IBM identified four steppingstones on the path to SOA nirvana and its full business benefits 1. Make applications available as Web services to multiple consumers via a middle-tier Web application server. This is an ideal entry point for those wishing to deploy an SOA with existing enterprise applications Target customer retention or operational efficiency projects Work with multiple consumers to correctly define the granularity of your services Pay proper attention to keeping the services and the applications loosely co
11
#12
The pathway to a service-oriented architecture 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. 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. In an SOA world, business tasks are accomplished by executing a series of "se
12
Don Box, Microsoft
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,
13
Project Status, Plans
Status Plans FASNET CATT & Tools as services SEEDS (architecture)
14
Web Services: Connect, Communicate, Describe, Discover
Enabling Protocols of the Web Services architecture: Connect: Extensible Markup Language (XML) is the universal data format that makes connection and data sharing possible. Communicate. Simple Object Access Protocol (SOAP) is the new W3C protocol for data communication, e.g. making requests. Describe. Web Service Description Language (WSDL) describes the functions, parameters and the returned results from a service Discover. Universal Description, Discovery and Integration (UDDI) is a broad W3C effort for locating and understanding web services.
15
Data Acquisition and Usage Value Chain
Monitor Store Data 1 Monitor Store Data 2 Monitor Store Data n Virtual Int. Data Integrated Data 1 Integrated Data 2 Integrated Data n
16 This is different
Wrapper Wrapper Service Service Query View Mediators
17
#18
Note that in distributed systems responsibility is distributed. For NVODS responsibility for The data lies with the data providers. Responsibility Data location with the GCMD and NVODS. Application packages (Matlab, Ferret, Excel…) with the developers of these packages. (Services??) The data access protocol lies with OPeNDAP.
18
Data Processing in Service Oriented Architecture
Data Values Immediacy Quality Lose Coupling of data Open data processing – let competitive approaches deliver the appropriate products to the right place
19
Comments