19
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.

Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

  • View
    219

  • Download
    2

Embed Size (px)

Citation preview

Page 1: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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.

Page 2: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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.

Page 3: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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

Page 4: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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’

Page 5: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

Web Programs Built on DataFed Infrastructure

Page 6: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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

Page 7: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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

Page 8: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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

Page 9: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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

Page 10: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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

Page 11: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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.

Page 12: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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.

Page 13: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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.

Page 14: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

Project Status, Plans

• Status

• Plans– FASNET

– CATT & Tools as services

– SEEDS (architecture)

Page 15: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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.

Page 16: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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

Page 17: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

Mediated Service-Oriented (Peer-to-Peer) Architecture

Wrapper Wrapper

Service

Service

Query View

Mediators

Page 18: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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.

Page 19: Service-Oriented Architecture Service-oriented architecture (SOA): An architecture built around a collection of reusable components with well- defined

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