21 October 2008 CIS 340# 1

What Does It Mean?

XWIF XML Web Services Integration Framework

SOAP Simple Object Access Protocol

Web service (WS)

•are application components •communicate using open protocols •self-contained and self-describing •can be used by other applications •XML is their base

SOA Service Oriented Architecture

Native Coming as part of the original

Not manipulated

21 October 2008 CIS 340# 2

21 October 2008 CIS 340# 3

21 October 2008 CIS 340# 4

21 October 2008 CIS 340# 5

21 October 2008 CIS 340# 6

The idea of SOA• Don’t throw things out

– You take the stuff (software assets) that you use every day — well, the best of the stuff you use every day — and package it in a way that lets you use it, reuse it, and keep on reusing it.

– These important stuff (programs) become business services• When you need to change a business policy

– Change it in one place and, because the same service is used everywhere,

– You have consistency throughout your organization.– Avoid redundancy

21 October 2008 CIS 340# 7

The idea of SOA - example• If you decide to create a new department in your

organization, – you are not going to create a new Accounting department,

new Human Resources department, new Legal department, new Cleaning department, new Training department, and new Travel department to go along with it.

– you will use your existing Accounting department (you may have to add staff), your existing HR, and your existing Cleaning, Training, and Travel departments to — note the expression — service this new department.

21 October 2008 CIS 340# 8

21 October 2008 CIS 340# 9

Strategy Insight (repeated)Key Elements

1. IT & business managers partnerpartner to model essential business interactions

2. IT assets are “reusable,” “extensible,” “investments”

3. IT builds upon industry standardsindustry standards to link – to dance -- with assets

4. IT builds technology services (use SOA) essentially consistent withconsistent with business services

21 October 2008 CIS 340# 10

SOA

• Loosely coupled approach

• Web-enabled

Def:Def:

Software architecture vs. SOA

21 October 2008 CIS 340# 11

21 October 2008 CIS 340# 12

Business Service

“... the logical encapsulation of business function ...” (p. 19)

Logical

Encapsulate

Business

Function

Def:Def:

Simple in principle

Practice?

21 October 2008 CIS 340# 13

SOA ComplicationsGOAL for software applications:

Modular Reusable Bug-free (tested) Accepted (user-

approved)

Complications:1. Keeping business logic separate and unmeshed

with “plumbing”

2. Legacy systems are THERE; modifications are not so “simple” to implement

3. Applications can be tangled meshes of legacy code that no one wants – or should – untangle

4. SOA “supervisor” is service-level “OS”

SOA Complications (1)Keeping business logic separate and unmeshed with “plumbing”• Business applications

– comprise lines of instructions (program code) – tell computers what actions to take

• Two types of instructions – as business logic

• add an item line to the order– simply plumbing - computer-level directives

• check that the printer is available• Both types are necessary.

– If you don’t describe the application’s activity in simple business logic (purchase orders, products, customers, accounts, and so on), you quickly lose sight of what you’re trying to achieve.

– If you don’t describe in computer terms exactly how the computer should carry out its task, the software simply won’t work.

• Challenge - The separation of concerns– Keep the business logic separate from the plumbing

• because you need to control both at the same time (why) -

21 October 2008 CIS 340# 14

21 October 2008 CIS 340# 15

SOA Complications (2)• Legacy systems are THERE; modifications are not so “simple” to implement

21 October 2008 CIS 340# 16

It interacts with the existing Invoicing system to send out an invoice. To make it possible for the Invoicing system to work inthis way, we create a simple “adapter.”

SOA Complications (3)Applications can be tangled meshes of legacy code that no one wants – or

should – untangle

• Consider the layers of applications on which your current business runs as archaeological layers. What are you going to do?

• Two options– Digging in the dirt: understand in detail how each layer works, how each

is connected to various components, and how the thing is managed,• it would take years and, because business and its applications are

continually changing, you would never be done.– Using magical black box: do not know how a CPU works but understand

how to use it to execute programs.• Intelligent black-boxing

– is an important aspect of SOA. – With a SOA, you can build a whole new computing environment by using

all the resources that you already have by treating many components as black boxes.

“If it ain’t broke, don’t fix it.”

21 October 2008 CIS 340# 17

SOA Complications (4)Who is in charge?

• You are wrapping your ugly code into nice black boxes, making services out of existing applications, and life is wonderful. Right? Uh, not exactly.

• How exactly are components strung together to ensure the end-to- end service you expect?

– For example, how do you know that, when you place your restaurant order, food (specifically the food you ordered) will be prepared and delivered to you in a timely fashion?

• SOA supervisor– acts something like a traffic cop and helps prevent SOA accidents– manages the end-to-end computer process created by connecting all the

other software components together. • Applications are divided between

– external components (components outside the corporate network) • the credit -checking component

– internal components (components inside the corporate network).

21 October 2008 CIS 340# 18

21 October 2008 CIS 340# 19

21 October 2008 CIS 340# 20

SOA (p. 27)

• SOA is for building business applications.

– Many legitimate approaches to software architecture exist, and SOA is not intended for building every kind of software. It is intended explicitly for building business applications.

• SOA is a black-box component architecture.

– SOA deliberately hides complexity wherever possible, and the idea of the black box is integral to SOA. The black box enables the reuse of existing business applications by adding a fairly simple adapter to them, no matter how they were built.

• SOA components are loosely coupled.

– The term “loosely coupled” refers to how two components interact within a SOA. One component passes data to another component and makes a request. The second component carries out the request and, if necessary, passes data back to the first. The emphasis is on simplicity and autonomy. Each component offers a small range of simple services to other components.

• SOA components are orchestrated to link together through business processes to deliver a well-defined level of service.

– SOA creates a simple arrangement of components that can, collectively, deliver a very complex business service. Simultaneously, SOA must provide acceptable service levels.

21 October 2008 CIS 340# 22

Pieces Enabling Integration• Adapters

• Gateways• Connectors• Component Bridges• Web services (by definition)

• Design: “exposes a programmatic interface that can

be used to interact with the legacy environment it represents”

• Intermediaries• WS domain (hold)

• Interceptors• WS domain (hold)

21 October 2008 CIS 340# 23

Architectures To Address

• One-Way Integration

• Point-to-Point Integration• Homogeneous apps• Heterogeneous apps• Homogeneous, component-based apps• Heterogeneous, component-based apps

• Centralized Database

21 October 2008 CIS 340# 24

Architectures To Address: Dimensions

• Data exchange• Data format conversion• Delivery of data• Data validation• Performance• Security• Transaction support• Additional interoperability• Extensibility

21 October 2008 CIS 340# 25

Service Models To Address: Dimensions

Models• Proxy services• Wrapper services• Coordination services

Dimensions»Anticipated usage volume»Interface design

characteristics»Message types»Deployment requirements

21 October 2008 CIS 340# 26

Service Models for Application Integration

Proxy services– LegApp accesses capability

as thoughas though a native interface– Easy to create– Inefficient, but gets the job done– RPC-centric

Wrapper services– Expose specific parts of LegApp through a

service interface– Custom-developed – Amount of “exposure” depends on the degree

of legacy logic being relied upon by the adapter

– Adapter is the specialized software realizing the “wrapping”

– RPC-centric or document-centric

21 October 2008 CIS 340# 27

Service Models for Application Integration: Wrappers vs. Proxies

• WR custom-developed• PR auto-generated code, mark-up

• WR encapsulated functionality via an adapter• PR mirror (mock-up) application interface

• WR designed to expose a select target of logic of the LegApp

• PR duplicate a LegApp interface

• WR use RPC & document messaging• PR relies on RPC messaging

• BOTH do not introduce new business logic

21 October 2008 CIS 340# 28

Service Models for Application Integration

Coordination services / Coordinators– Center on ACID requirements

– Grouping of three sub-services1. Context creation – A query!!

2. Registration of coordination contexts

3. Protocol selection

– Document-centric messaging

– ““The”The” option for WS deployment

21 October 2008 CIS 340# 29

Architectures: Point-to-Point Integration

• Homogeneous apps• Heterogeneous apps• Homogeneous, component-based apps• Heterogeneous, component-based apps

21 October 2008 CIS 340# 30

Next

Continuing with examples of approaches

XML concepts

Moving on to development points