View
219
Download
2
Embed Size (px)
Citation preview
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.
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.
Mediator-Based Integration Architecture (Wiederhold, 1992)
• 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
Service Oriented Architecture
Control
Data
Process Process
Process
Peer-to-peer network representation
Data ServiceCatalog
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’
Web Programs Built on DataFed Infrastructure
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
Render
Service Chaining in Spatio-Temporal Data Browser
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 DataSQL Table
OLAP
Satellite
Images
Data Sources
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
Dev
ice
Dri
vers
Wra
pp
ers App State Data
Flow Interpreter
Core
Web Services
WSDL
Ports
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
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
The pathway to a service-oriented architectureBob 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 coupled.
• 2. Choreography of web services– Create business logic outside the boundaries of any one application– Make new apps easy to adjust as business conditions or strategy require– Keep in mind asynchronous services as well as compensation for sequences of actions that don't complete successfully– Don’t forget managing the processes and services
• 3. Leverage existing integration tools– leverage your existing enterprise messaging software; enterprise messaging and brokers– Web services give you an easy entry to SOA adoption– WS are not the gamut of what service orientation means; Modeling is likely required– Integration with your portal for "people integration" will also probably happen
• 4. Be flexible, responsive on-demand business– Use SOA to gain efficiencies, better use of software and information assets, and competitive differentiation.
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 "services," 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.
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
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.
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.
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.
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 "service-oriented integration" and will probably affect a single department or a business unit such as a call center.
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.
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 "people integration" will also probably happen here if you didn't already do this at the previous SOA adoption point.
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.
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.
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, 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 "shrink" 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.
Project Status, Plans
• Status
• Plans– FASNET
– CATT & Tools as services
– SEEDS (architecture)
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.
Data Acquisition and Usage Value Chain
Monitor StoreData 1
Monitor StoreData 2
Monitor StoreData n
Virtual Int. Data
Integrated Data 1
Integrated Data 2
Integrated Data n
Mediated Service-Oriented (Peer-to-Peer) Architecture
Wrapper Wrapper
Service
Service
Query View
Mediators
Note that in distributed systems responsibility is distributed. For NVODS responsibility for
The data lies with the data providers.
ResponsibilityResponsibility
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.
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