View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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