architecture deep dive - dovel...

1

Copyright © 2006, ZapThink, LLC 1

Architecture Deep Dive

Jason BloombergZapThink, LLC

Take Credit Code: NODEEP


How to Think Service-Oriented

• Think of software functionality as Services

• Think of Services as sending and/or receiving messages

• Think of integration as a byproduct of Service composition

2


• Business-oriented requests and responses

• Blocks of information exchanged

• Encapsulate APIs into fine-grained, atomic Services and compose them into coarse-grained, business Services

J

Service Orientation Tenet:Coarse Granularity


Granularity Illustrated: Size of Lego Blocks

• Too small?– Difficult to build anything

• To big?– Too inflexible

• Just right?– Depends on the project at

hand– Most situations require a

mix of sizes

3


Granularity Example

• Fine-grained interaction:» I’d like to order a shirt.

» What size would you like?» Size XL.

» What style?» The one on page 30

of your catalog.» Which catalog is that?

» …

• Coarse-grained interaction:» Fill in the order form online

with all required information» Click submit

» Receive “Thank you, your order is complete” page

» …


• The Web is synchronous: click a button and wait for a response

• Service interactions can also be asynchronous: allow for long-running processes

• The SOAP specification has always allowed for asynchronous behavior

• Messages can be thought of as events – either Service providers or consumers can generate them

• Synchronous behavior is a special case of asynchronous, handled thru metadata– For example, policy that states that a response is required in 3

seconds

J

Service Orientation Tenet: Asynchrony

4


What about Coupling?

• Coupling – the level of common knowledge necessary in a distributed computing exchange

• Tight coupling – one participant must have detailed knowledge about the other participant

• Full decoupling – the two participants need have no knowledge about each other in order to interact

• Loose coupling – the two participants may have specific, limited knowledge about each other– Changing one doesn’t break the other, within the bounds of

the contract


The Web: Loose Coupling in Action

• Client/server tightly coupled clients and servers– Most server updates required new client

software

• The Web solved this problem– Any browser could access any Web

server– Web sites could change without

requiring new software on the client– The secret sauce: standards like

HTTP and HTML

5


Levels of Coupling

• At the transport protocol layer– Example: MQ HTTP

• At the message protocol layer– Example: SOAP 1.1 SOAP 1.2

• At the schema layer– Example: ACORD PC XML 1.7 ACORD PC XML 1.8

• At the semantic layer– Example: “Gender” is “M”, “F”, or “unspecified”

”Gender” is “M”, “F”, or “N/A”


Loose Coupling and Context

• “Perfect” loose coupling– I have no idea how many consumers or users

there will be, or how they will want to access my Service

– Would lead to very high capacity requirements

• Loose coupling “within context”– If I have some knowledge about the context of

the consumers (for example, that they are all internal to my organization), my capacity planning can be more economical

The architect must balance loose coupling The architect must balance loose coupling with context to optimize TCOwith context to optimize TCO

6


Service Contracts & Loose Coupling

• Service contract – a document external to each participant that provides the information each participant needs to interact with the other

• The service contract is the mechanism that enables loose coupling

• Web Services Description Language(WSDL) – standard Service contract language


The Challenges with doing SOA right

• Architectural issues– Enterprise Architecture capability maturity– Building SOA the right way– XML Performance issues

• Organizational issues– Pulling together the SOA team– Who’s in charge of Services?– How will you pay for Services?– How will SOA affect your organization moving forward?

• New tool & infrastructure requirements– Messaging– Contract development– Composite application development– Metadata management– Policy infrastructure

7


Emerging Best Practices

• Architecture is a discipline– SOA mandates new practices

and methods

• Best Practice: Iterative development– Start small, and let it grow

• Best Practice: Contract-first, top-down as well as bottom-up

• Best Practice: Implementing governance sooner than later

You can’t get SOA from a software vendor!


The End of RPC

• Remote Procedure Call (RPC) is the traditional approach to distributed computing that represents distributed resources as local

• Pro: abstracts complexity of distributed environment

• Cons:– Hard to handle exceptions– Typically not firewall/B2B friendly– Tightly coupled– Favors homogeneous technologies

8


Interoperability vs. Portability

• Traditional RPC-based distributed computing based upon portability– Object serialization– Remote method invocation– Simulate one local computer

• SOA based upon interoperability– Code remains in place, known only by contracts– Computers interact via messages

““Write once, run anywhereWrite once, run anywhere”” gives way to gives way to ““write once, write once, accessaccess anywhereanywhere””


RPC vs. Document-Style

• Traditional RPC: “Tell Me What to Do”– The Body Contains the Instruction, not just the data.

For example:• Service: CustomerInfo• Body:

<operation>DeleteCustomerRecord(“344”)</operation>

• Document Style: “Just the Facts, Ma’am”– The Body only contains the data, the Service needs

to know what to do• Service: DeleteCustomer• Body:

– <ID>344</ID>

Want loose coupling? Go Document Style! Want loose coupling? Go Document Style!

9


What is Architecture?

The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution. (IEEE P1471/D5.3)


The SOA Metamodel

Business Model(Use Cases) Service Model Platform

Dependent Models

Deployment View

System Architects &System Engineers

Implementation View

Technical Architects & Developers

Process View

Business Analysts

Logical View

Line-of-Business Users

TechnologyViews

BusinessViews

Use-case View

Service-Oriented Architects

Copyright © 2003 ZapThink LLC

10


SOA Foundation: Model-Driven Architecture

• Object Management Group (OMG) initiative

• Concepts of models, metamodels, and the Meta-Object Facility, which is a meta-metamodel

• Platform independent model and platform dependent models

• Model-driven development

• Weakness: Doesn’t (yet) take into account changing requirements


Model-Driven Metadata

• Tools that generate metadata from models

• Reduce complexity, increase flexibility

• Important part of SOA approach

Source: Contivo

Source: TenFold

11


TOGAF and SOA

Source: The Open Group

• The Open Group Architecture Framework (TOGAF) is a set of methods & tools for developing a range of different IT architectures

• Enables IT users to design, evaluate, and build the right architecture for their organization

• Reduces the costs of planning, designing, and implementing architectures

• The TOGAF Architecture Development Method (ADM) connects architecture with business requirements (see diagram)

• Offers many useful tools for SOA


SOA Foundation: The 4+1 View Model

Logical ViewFunctional requirements

Deployment ViewPlatforms

Process ViewProcesses

Implementation ViewComponents

Use Case ViewSOAs

Data View

Information View

12


SOA Foundation: The Zachman Framework


The Zachman Framework (cont.)

13


SOA & Zachman

DATA FUNCTION NETWORK

SOA


SOA & Zachman (cont.)

SemanticModel

Messages

Events

GovernanceFramework

Policies

RulesPhysical

DataModel

BusinessStrategy

ServiceLifecycle

ServiceNetwork

UIServices

ServiceConsumers

Users

ServiceModel

ProcessModel

SystemArchitecture

ServiceInfra-

structure

BusinessEntities

ComponentArchitecture

LogicalDataModel

SOBAsThe

OrganizationThe

InternetBusinessChange

IdentitiesNetworkNodes

ComponentsSchemas AssertionsElements

State ofthe Art!

14


Building the Service Model

• Service model is abstract representation of– Requirements for Services– Services in production

• Model represents all relevant views

• Model actualized in Service contracts and other Service metadata

Service Metadata

Service Model

Business ModelImplementation

Models


The Service Model: Processes

Source: IBM

15


The Service Model: Building Business Services

Source: IBM


Thank You!

ZapThink is an advisory, analysis, & influence firm focused exclusively on Service-Oriented Architecture, Web Services, & Enterprise Web 2.0.

Read our new book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business.

Jason Bloomberg

[email protected] Schmelzer

[email protected]

architecture deep dive - dovel...

Documents