architecture deep dive - dovel...
TRANSCRIPT
1
Copyright © 2006, ZapThink, LLC 1
Architecture Deep Dive
Jason BloombergZapThink, LLC
Take Credit Code: NODEEP
Copyright © 2006, ZapThink, LLC 2
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
Copyright © 2006, ZapThink, LLC 3
• 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
Copyright © 2006, ZapThink, LLC 4
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
Copyright © 2006, ZapThink, LLC 5
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
» …
Copyright © 2006, ZapThink, LLC 6
• 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
Copyright © 2006, ZapThink, LLC 7
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
Copyright © 2006, ZapThink, LLC 8
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
Copyright © 2006, ZapThink, LLC 9
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”
Copyright © 2006, ZapThink, LLC 10
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
Copyright © 2006, ZapThink, LLC 11
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
Copyright © 2006, ZapThink, LLC 12
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
Copyright © 2006, ZapThink, LLC 13
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!
Copyright © 2006, ZapThink, LLC 14
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
Copyright © 2006, ZapThink, LLC 15
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””
Copyright © 2006, ZapThink, LLC 16
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
Copyright © 2006, ZapThink, LLC 17
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)
Copyright © 2006, ZapThink, LLC 18
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
Copyright © 2006, ZapThink, LLC 19
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
Copyright © 2006, ZapThink, LLC 20
Model-Driven Metadata
• Tools that generate metadata from models
• Reduce complexity, increase flexibility
• Important part of SOA approach
Source: Contivo
Source: TenFold
11
Copyright © 2006, ZapThink, LLC 21
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
Copyright © 2006, ZapThink, LLC 22
SOA Foundation: The 4+1 View Model
Logical ViewFunctional requirements
Deployment ViewPlatforms
Process ViewProcesses
Implementation ViewComponents
Use Case ViewSOAs
Data View
Information View
12
Copyright © 2006, ZapThink, LLC 23
SOA Foundation: The Zachman Framework
Copyright © 2006, ZapThink, LLC 24
The Zachman Framework (cont.)
13
Copyright © 2006, ZapThink, LLC 25
SOA & Zachman
DATA FUNCTION NETWORK
SOA
Copyright © 2006, ZapThink, LLC 26
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
Copyright © 2006, ZapThink, LLC 27
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
Copyright © 2006, ZapThink, LLC 28
The Service Model: Processes
Source: IBM
15
Copyright © 2006, ZapThink, LLC 29
The Service Model: Building Business Services
Source: IBM
Copyright © 2006, ZapThink, LLC 30
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