Transcript ServiceOrientedArchitecture

Service-Oriented Architecture
Service-oriented architecture (SOA): An architecture
built around a collection of reusable components with welldefined 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
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
Client-Server Architecture:
User accesses, processes and
integrates data by customized tools
Result: User Carries the Burden
User Tasks:
In current client-server architectures the user
carries much of the burden of integration.
Find servers
Server
Reformat data
Custom process
User
Server
Server
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
Query
View
Service
Mediators
Wrapper
Service
Wrapper
Busse et. al, 1999
Service Oriented Architecture
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
Peer-to-peer network representation
Service chain representation
Data
Control
Data
Chain 2
Process
Service
Chain 1
Process
Chain 3
User Carries less Burden
In service-oriented peer-to peer architecture,
the user is aided by software ‘agents’
Process
User Tasks:
Catalog
Data Service
Find data and services
Compose service chains
Expose output
Process
Web Programs Built on DataFed Infrastructure
Generic Data Flow and Processing in DATAFED
View
Wrapper
Physical
Data
Abstract Data
Access
Abstract
Data
Process
Data
Data
Portrayal/
Render
Processed
Data
Portrayed
Data
DataView 1
DataView 2
DataView 3
Physical Data
Abstract Data
Processed Data
View Data
Resides in autonomous
servers; accessed by viewspecific wrappers which
yield abstract data ‘slices’
Abstract data slices are
requested by viewers;
uniform data are delivered
by wrapper services
Data passed through
filtering, aggregation,
fusion and other web
services
Processed data are delivered
to the user as multi-layer
views by portrayal and
overlay web services
Service Chaining in Spatio-Temporal Data Browser
Data Sources
Homogenizer
Catalog
XDim Data
Wrapper
SQL Table
Mediator
OGC-Compliant GIS Services
Spatial Portrayal
Spatial Overlay
Client Browser
OLAP
GIS Data
Vector
nDim Data Cube
Spatial Slice
Time-Series Services
Time Portrayal
Satellite
Time Overlay
Time Slice
Images
Cursor/Controller
Maintain Data
Find/Bind Data
Portray
Overlay
Render
An Application Program: Voyager Data Browser
Controls
Data Sources
Wrappers
App State Data
Flow Interpreter
Core
I/O Layer
Device Drivers
Ports
Displays
WSDL
Web Services
•
•
•
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
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
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 datacrunching legacy systems must mesh with
agile front-facing applications
•
•
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.
•
The pathway to a service-oriented architecture
Bob Sutor, IBM
•
In an SOA world, business tasks are accomplished by executing a series of "services,“
–
–
–
–
–
•
1. Make applications available as Web services to multiple consumers via a middle-tier Web application server.
–
–
–
–
•
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
–
–
–
–
•
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
–
–
–
–
•
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
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. Serviceorientation 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
Monitor
Monitor
Data 1
Data 2
Data n
Store
Store
Store
Integrated
Data 1
Integrated
Data 2
Integrated
Data n
Virtual Int.
Data
Mediated Service-Oriented (Peer-to-Peer) Architecture
Query
View
Service
Mediators
Wrapper
Service
Wrapper
Responsibility
Note that in distributed systems responsibility is distributed. For
NVODS responsibility for
The data lies with the data providers.
 The data access protocol lies with OPeNDAP.
 Application packages (Matlab, Ferret, Excel…) with the
developers of these packages. (Services??)
 Data location with the GCMD and NVODS.
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