level set – what is soa?doveltech.com › wp-content › uploads › 2017 › 09 ›...

1

Copyright © 2005, ZapThink, LLC

Service-Oriented ArchitectureImplementation Roadmap

Presentation for Swiss ClientOctober 26, 2005

Jason Bloomberg and Ronald Schmelzer Senior AnalystsZapThink, LLC

Take Credit Code: SWISSIR


Level Set – What is SOA?

• SOA is architecture – a set of best practices for the organization and use of IT

• Abstracts software functionality as loosely-coupled, business-oriented Services

• Services can be composed into business processes (which are also Services) in a declarative manner

2


Service-Oriented Architecture

• The Definition:– An approach to building and managing distributed computing

infrastructures that considers IT resources as Services available and discoverable on a network.

• The Implication:– Rather than dealing with isolated systems that must be

integrated after the fact, Service Orientation provides business users with understandable Services they can call upon and compose into business processes as needed – building systems that can adapt as the business changes.

• The Benefit:– The Service Orientation vision is therefore one of providing the

business values of agility and flexibility for users of technology, coupled with an abstraction layer that simplifies the complexity of today’s heterogeneous IT environments from those users.


SOA shifts the way we think

Compose ServicesIntegrate Silos

Loosely Coupled, Agile and Adaptive

Tightly Coupled

Designed to changeDesigned to last

Favors Heterogeneous TechnologyFavors Homogeneous Technology

Architecture makes it workMiddleware makes it work

Business centeredCost centered

Interactive and iterative development

Long development cycle

Process OrientedCode Oriented

Service Oriented ArchitectureTraditional Distributed Computing

3


Characteristics of SOA

Services are loosely coupled – making a change to a Service provider does not mandate changing any Service consumers

Business processes are composed of Services, and are in turn exposed as Services

Services are policy-driven – business users can change how a Service behaves

Systems are inherently integrated by virtue of composable services –not through layers of middleware

Services leverage legacy systems – SOA does not mandate replacement of runtime infrastructure

In SOA, metadata control how the system behaves, not code. Business logic trumps application logic

In SOA, it’s the contracted interface that matters, not the underlying runtime environment.


The Benefits of SOA…

Reduced cost of integration

Improved value from legacy applications

Reuse leading to reduced redundancy

Greater visibility for governance & compliance

Increased reuse of software assets

Business agility…– Respond quickly & efficiently to business change– Leverage change for competitive advantage

4


SOA Hotspots

• Four key areas of SOA investment– Reduction in integration expense– Increase in Service / asset reuse– Increase in business agility– Enablement of governance &

compliance

• Key Problem areas– EAI replacement– Legacy enablement/migration– Shared Service development– Governance– Embedding processes in the

extended enterprise


Don’t Get Lost in the Terminology

• There are many styles for SOA implementation

• Focus on your goals: Reuse? Governance? Reduced integration cost? Agility?

ESB? EAI?

SOA?EDA?EDA?

Fabric?

Abstraction?SOA Infrastructure?

Service Grid?Service Network?

5


Web Services make implementing SOA easier, but they aren’t the

same

MainframeLogic

MainframeLogic

EISEIS CustomApp

CustomApp

Web Services Web Services Web Services

Security Security Security

Messaging Messaging Messaging

TransactionsTransactions

MainframeLogic

MainframeLogic

EISEIS CustomApp

CustomApp

Web Services Web ServicesWeb Services

SOA Abstraction LayerSOA Abstraction LayerTransactions Messaging Security

Business Services Data Services Discovery

Man

agem

ent

Mon

itorin

g

Standard architecture with Web Services

SOA leveraging Web Services

Source: HP


Web Services are the Trees….

Service Orientation is the Forest

6


Service orientation…the next big thing?

Approach TimeframeProgramming

ModelBusiness

Motivations

Mainframe timesharing1960s –1980s

Procedural (COBOL) Automated business

Client/server 1980s-1990s

Database (SQL) and fat client (PowerBuilder, Visual Basic)

Computing power on the desktop

n-Tier/Web 1990s-2000sObject-oriented (Java, COM)

Internet/eBusiness

Service orientation 2000sService-oriented (SOAP, WSDL, UDDI)

Business agility


SOA is a discipline…

• Implementing a Service-Oriented Architecture is a journeyjourney

• Moving from proprietary interfaces to standards-based ones is just the first step…

• SOAs require a combination of security, management, governance, integration, process, and architecture tools

• What are the right steps to guarantee overall success?

• How can you guarantee an ROI while reducing risk?

7


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)


In Particular, SOA is Enterprise Architecture

Enterprise architecture includes:

• An aggregated architecture of all the individual IT systems within an organization

• The human element within the enterprise

• Systems, people, and organizational constructs at other companies that have relationships with the enterprise

• Individual consumers who are that enterprise’s customers

• Corporate governance

8


The Challenges with doing SOA right

• Architecture? Sounds difficult!• Performance issues around XML• New tool and infrastructure requirements

– Messaging– Contract development– Composite application development– Metadata management– Policy infrastructure

• But… doesn’t this infrastructure already exist?


SOA’s Little Secret

• You can build SOA with whatever software you already have (for the most part)

• When considering purchasing software for your SOA initiative, look to fill the functionality gaps in your current portfolio

• Don’t just add middleware for your middleware!

9


The ZapThink SOA Roadmap


ZapThink’s SOA Implementation Roadmap

Heterogeneous Systems with Proprietary Interfaces

Manage Services

Implement the SOA Metamodel

Service-Oriented ProcessSemantic Integration

Dynamic Service Discovery

Secure Service Interfaces

Wrap Legacy Systems in Services Interfaces

Service-Oriented Enterprise

Enterprise SOA Buildout

Mission-Critical SOA

SOA Pilots

“Grass Roots” Web Services Implementations

Create a Governance Framework

Contract-First Development

Cross-Departmental SOA

10


The Old Way: Rip & Replace

• Expensive & risky to replace

• Expensive & risky to keep around

• Absolutely necessary for the business


The New Way: Squeeze Value

• SOA enables thrift: getting more value out of existing assets

• Wrapping as Web Services only the first step

• Challenge: Building Services from Legacy Systems at the rightlevel of granularity

11


SOA Abstracts the Plumbing

• Goal is reusable, composable business Services

• Infrastructure hidden under Services layer of abstraction


The OSI Stack Revisited

• Content Security, as well as– Semantics– Taxonomies– Policy– Schemas– …

7

6

5

4

3

1

2Traditional perimeterTraditional perimeter--

based approaches wholly based approaches wholly inadequateinadequate

12


The Security Context Challenge

rschmelzer

RonSchmelzer

rschm123

Selective

Read / Write

Read Only

Full Read/Write???

???


Building SOA the Right Way

• SOA is all about continuous and sometimes unpredictable change

• Development issues

– How to handle versioning?

– How to handle metadata management?

– How to develop changing policies?

• Runtime issues

– Service availability

– Policy enforcement

– Guarantee service-level agreement

– Maintain low TCO

13


Challenge: Service Granularity

• The trick of building composable Services is building at the right level of granularity

• Challenges:– Engraining business logic into code– Decomposing legacy services that are not fine-

grained enough

• Method– Top-down process decomposition, vs. bottom-

up Service development– Must be iterative


Contract-First Development

• Service contracts specify required functionality to IT and provided functionality to the business

• Service model represents the clearinghouse for information about IT environment

• Contracts go beyond WSDL:– Usage policies– Security policies– Consumer delivery contracts– Service-level agreements, etc.

14


What’s in a Contract?

Functional Requirements

Non-Functional Requirements

Service Operations Infrastructure URI

Security QoS Transactions Commerce / Biz Rules

Service Level Semantics Process


What’s NOT in the Contract

A "Contract" is an expression of A "Contract" is an expression of visiblevisible aspects of Service behavior.aspects of Service behavior.

It does NOT specify:• Service Implementation Details

– Programming model – Object references– In-memory representations

• Examples– Exposing Java Classes– Serialization of Java Objects

15


Important Points: Managing Services

• You need management when you offer your first “mission critical” Web Service (don’t wait!)

• Management is critical for building and running enterprise-class SOAs

• The Service-Oriented Management space is still in flux


Service-Oriented Management

• Are your Services up and running?

• Are the right consumers accessing the right Services?

• How do you keep consumers & producers of Services loosely coupled when Services change?

• How do you fix things when something goes wrong?

• Are you providing the required quality of Service?

• SOA enablement…

16


SOA Enablement…

• Provide and enforce the SOA layer of abstraction

• Combine fine-grained APIs into coarse-grained business Services

• Mask complexity of underlying technology: message protocols, adapters, APIs, etc.

• Handle quality of service, scalability, etc. “behind the scenes”


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

17


CompositeApplication

Delivery

BusinessServices

BusinessProcesses

SOA Fabric AtomicServices

Data Integration

Legacy Applications

and Middleware

SOA: A Technology View

Databases

Governance and Security InfrastructureGovernance and Security Infrastructure

SecuritySecurity

ManagementManagement

RoutingRouting

TransformTransform

AA

BBCC

DD

EE

AA

BBCC

DD

EE

MessagingMessaging

Rich Rich ClientsClients

Composite Composite AppsApps

DiscoveryDiscovery

Source: MW2 Consulting


• What does it mean to build business logic in metadata?

• The power is not the interface specification, but in the Service abstraction

• Code meets requirements of contracts – but does not specify a contract of its own!

J

Fundamental Idea: Business Logic in Metadata

Source: Copyright © 2002 ZapThink, LLC

ContentManagement

Web Site

File System

RDBMS

Office Documents

B2B Exchanges

Directory

ERP / CRMSystems

Mainframe / Legacy

NetworkedDevices

No

N- o

r S

EM

I-S

TR

UC

TU

RE

D

ST

RU

CT

UR

ED

Source: IBM

18


Metadata Management Requirements

• In an SOA, business logic is in metadata, not code• Types of metadata

– Service interfaces– Business process flows– Policy definitions– Event messages and types– Schema and semantics

• Need: development tools and methodologies

This is the state of the art for SOAThis is the state of the art for SOA


What are we talking about?

• Metadata Management– SOA’s not about the code… it’s about the

metadata

• Definitions–Repository: Where assets are stored–Registry: How to find and work with the assets you need –wherever they are–Products have aspects of both

19


Standards vs. Products

• STANDARDS provide interoperability while PRODUCTS provide functionality

• UDDI: A standard for Registry Interoperability; ebXML & JAXR other registry-related standards (may be more?)

• UDDI and the other standards are NOT products!• There are many other ways to interact with registries• Registries do more than just UDDI• Repositories have a UDDI role, too!


Service Registry/Repository: Roles

Enablement

How do I quickly

• design

• develop

• deploy

my Web services SOA software?

Publishing

How do I certify and approve my services for:

• company

• IT

• SOA

standards and deployment readiness?

Management

How do I make services scale for:

• availability

• reliability

• integrity

• measure overall quality?

Discovery

How do I:

• share

• find

• use

my services anytime, anyplace, anywhere?

Source: Systinet

20


Service Registry/Repository: Roles

• Mapping Business Processes to SOA Model

• Business, IT governance development

• SOA foundation development

• Web services development

Enablement

• Registering Business Services and SOA information

• Certification Process

• Change Management

• Approval Process & Management

Publishing

• Locating and using Services

• Design time usage

• Run-time usage

• Configuration and Change

• Coordination Management

Discovery

• Operating, monitoring, and changing services

•Change, Impact Analysis

•SLA & Policy Management

• Integration -Security & Identity Mgmt

•Log, Reports

Management

Source: Systinet


What is a Business Process?

• What a business does

• Range from fully manual (no IT involvement) to fully automated (no human involvement)

• Most processes are partially automated

21


Business Process the Old Way…

• People plugged into rigid processes• Inflexible & brittle


Business Process the Service-Oriented Way…

• IT resources (among other resources) available to the business as needed

• Business users compose applications on the fly

22


The Key: The Services Abstraction

• Services abstract underlying functionality & data to the business

• Also abstract business requirements to IT• Lines of business should work with

metadata — without direct IT involvement

Service Model

Service Metadata

ExistingInfrastructure

Lines ofBusiness


Service-Oriented Process

• Processes that are coarse-grained: composedof Services and exposed as Services

• Processes that are loosely coupled: a change to a process flow, activity, subprocess doesn’t effect other processes

• Processes that are asynchronous• Processes that are dynamically discoverable

PROCESSES THAT CAN RESPOND TO CHANGE

23


Role of Composite Applications

• Architecture guides composition of Services

• Legacy assets key part of Service-oriented composite apps

• Challenge: top-down process first or bottom-up system first?

• Benefit: combine old legacy processes with new composite business logic


Thank You!

Jason Bloomberg

[email protected] Schmelzer

[email protected]

Photos © Lisa Polucci