Service Oriented Architecture
overview by Alar Krist, nov 2006
Main sources:
Gartner Symposion materials 2006 nov
Oracle SOA day materials 2006 nov
SOA classic approach in WWW
http://en.wikipedia.org/wiki/Service-oriented_architecture
http://www-
128.ibm.com/developerworks/webservices/library/ws-soa-
term1/index.html?ca=drs-
http://www-128.ibm.com/developerworks/webservices/newto/
...
Service Oriented Architecture levels
SL - System / application level
TL - Technology / standards level
CL - Component level
SL - Main model of system level SOA
SL - Main principles of system level SOA
A system built with an SOA consists of
subsystems that interact in a loosely coupled
and with a well-defined contract
the subsystems are fully autonomous: each can
freely participate in interactions with a number of
other autonomous systems.
In addition, all interactions are governed by the
same contract or formal interface description
SL - The power of system level SOA
SOA allows autonomous subsystems to be
assembled into entities (SOA applications) that
can be as cohesive externally as applications
built with older architectural approaches (that is,
classic structured programming modularization,
or object-oriented paradigm).
The benefit of SOA s over these older
approaches is increased agility and greater
tolerance for change throughout the life cycle of
a system
SL - Description of SOA: metadata mgmnt
SL - Metedata management
Managing metadata and semantic reconciliation are
critical to an enterprise information management (EIM)
program.
EIM brings an organized approach to metadata
management, enabling optimization, abstraction and
semantic reconciliation of disparate metadata to support
reuse, consistency, integrity and shareability of
enterprise information assets.
Metadata is typically managed through metadata
repositories (centralized catalogs of metadata) and
metadata registries (federated metadata sources).
TL - Technology level of SOA
TL - Main technology aspects
WOA (e.g., IFaP, REST, POX, WS*, modular,
embeddable, distributable),
Data-Driven (e.g., XML, BPEL)
Rich Semantics (Metadata, eRDF, RDFa, microformats,
Semantic Web, Semantic Reconciliation)
Mashable Applications (Remix and scripting, PHP,
Javascript)
Build by example (show source, cloning),
Rich Client (just fast enough just in time, Ajax,
OfflineAjax, Flex, Microsoft, etc.)
Persistent Web (Caching, streaming, managed client)
TL - Stracegic view - Gartner 2006 nov
Strategic Imperative: Information and process
should be embedded in the Web, not just
communicated by the Web.
Strategic Planning Assumption: By 2010, WOA
will account for 60% of SOA development in the
enterprise (0.7 probability).
TL - Main concepts of WOA
TL - "Representational State Transfer"
how a well-designed Web application behaves: a
network of Web pages forms a virtual state machine,
allowing a user to progress through the application by
selecting a link or submitting a short data-entry form,
with each action resulting in a transition to the next state
of the application by transferring a representation of that
state to the user
REST describes the Web as a full blown application
architecture, not just a GUI architecture or a transport
architecture.
TL - Strategic Imperative: Move business volatility
into data, and move technology stability into code.
TL - Principles of SOA data driven approach
New focus is on modularizing data, not just modularizing
code.
Fold knowledge into data so program logic can be stupid
and robust
Procedural logic is hard for humans to verify, but quite
complex data structures are fairly easy to model and
anderstand
Data is more tractable than program logic
TL – Important standards of SOA
ERP/
Portal Legacy Apps
Security
Custom Apps
Web Application Reliability
& Services
Logging
Monitoring Process Flow Failover
Optimization Logic Dynamic Routing
WS
API Web services
ORCHESTRATE
MONITOR & OPTIMIZE INTERACT/ACCESS GATEWAY, ESB BUS SERVICES
BAM PORTAL JSR-168 BPEL, B Rules WS-Security XML/XML Schema
JMX ADF/ Struts/JSF XSLT/XQuery WS-Policy, SAML WSDL/WSIF
Web Services Mgmt SOAP JCA JMS
TL – Key problem areas by SOA layers!
Business services
Data models (decomposition, redesign, data access, ...)
Service models
Substance, essence, nature, definition of servise
How to describe
Decomposition, Granuality
Integration (interface models, ESB, security, service mgmnt, ...)
Business processes execution
BP modelling, analysis, design, BP as a service
BPEL – code and data decomposition, workflow models, ...
Business rules – BR description models, decomposition, ...
Interacition, access, UI (analysis, design, ADF, redesign)
Monitoring & optimizing (BP, services, SLA-s, components)
TL - Enterprise Service Bus
Routing QOS BPEL Transform Rules
Enterprise Service Bus – Integrate services
WSIF – platform independent interface
In Memory REST JCA COM+ SOAP
Core Features of an ESB – Virtualizes services
Connects Transports
adapters, web services over JMS, HTTP
Routes Translates
based on content/header protocols & formats
TL – ESB Pattern Summary
Point To Point
Adapter -> Transformation -> Adapter
Quick and Easy Integration
File to DB, Topic to Queue
Canonical Model
Integrate n+ Enterprise Applications
Domain Value Mapping
Dynamically Add New Subscribers
Routing Service
Decoupled Flexible Routing
Configurable in Rich Client
Services Visible to BPEL, BAM, WSM
TL – Introduction to BPEL
Markup language for composing a set of discrete
services into an end-to-end process flow
10+ years of research and development from Microsoft
(XLANG) and IBM (WSFL, FDML)
The best integration solution for XML and Web services
but also Java, JCA and JMS.
Rich support for async interactions, parallel processing
and exception management.
Leverages XML Schema, XSLT, XML Query,
WS-Security, WS-Addressing and WSIF.
Composability: A process flow is automatically
a service.
TL - BPEL, The Orchestrator
PORTAL Web Service
Java Service
? Database
Stored Procedures
J2EE ERP
SAP, Oracle, etc.
BPEL
IU User Tasks
TOMCAT
TL - Business Rules
Rules specify conditional actions or policies
If salary is less than $10,000 then deny loan application
If miles flown is greater than 50,000 then grant gold
status
Rules
Can be represented as simple if-then statements
Are declarative, not procedural
facts
Often generated by GUI programs Rules
Engine
Rules executed on Rules Engines results
Facts are input Application
Facts analyzed per Rules
Actions conditionally executed or results returned
TL - Rules Features: dynamic Fact Generation
Rules are conceptually simple
Facts: Data concerning the world
Rules: if () then
Actions: Simple returns or direct action calls
Example: If (quantity >= 12) then
give 20% discount
An action can be the generation of a new fact
This is called inferencing
Example: If (GPA > 3.5 and SAT > 1400) then
create scholarship-eligible Fact
facts
Rules
results
Engine
facts
TL - Rules Features: rules Programming Models
Rules "consulted" by applications
Procedural logic asserts facts to Rules engine
Results engine returns results
Procedural logic calls actions
Claim
Rules can call actions directly facts Rules
Procedural logic asserts results
Engine
facts to Rules engine Don't
Rules engine calls Application pay
fraud
Logic
actions directly alert
Especially attractive for notifications
Can access database info, etc.
TL – Appl Dev Framework model
TL – ADF model:
Unifies platform dependent BS
Enables you to work the same way with any UI and any
business service
Decouples UI from back-end business services
Uses EL to bind a component to a data control
Provides drag and drop data binding
TL – Example: Oracle SAO suite
BAM Analytics Events Monitoring
JDeveloper BPEL Process Manager
Native Human Business Web Services
Integrated
BPEL Workflow Rules Manager
Services
Environment Enterprise Service Bus
App Dev XSLT
Framework Adapters Routing Security
Transform
B2B Application Server UDDI
J2EE, WS-*, Event Services Registry
CL – Component level SOA - Service
Services are obviously at the heart of Service-
oriented architecture, and the term service is
widely used.
However, it means different things to different
people
“A service is a discoverable resource that
executes a repeatable task, and is described by
an externalized service specification." by IMB
CL - key concepts behind services
Business alignment: Services are not based on IT capabilities, but
on what the business needs. Services business alignment is
supported by service analysis and design techniques.
Specifications: Services are self-contained and described in terms
of interfaces, operations, semantics, dynamic behaviors, policies,
and qualities of service.
Reusability: Services reusability is supported by services
granularity design decisions.
Agreements: Services agreements are between entities, namely
services providers and consumers. These agreements are based on
services specification and not implementation.
Hosting and discoverability: As they go through their lifecycle,
services are hosted and discoverable, as supported by services
metadata, registries and repositories.
Aggregation: Loosely-coupled services are aggregated into intra- or
inter-enterprise business processes or composite applications.
Analysis techniques such as IBM's Service-Oriented Modeling and
Architecture (SOMA) exist to identify the list of appropriate services
based on the concepts listed above
CL - Architecture
The Open Group Architecture Forum (TOGAF) provides two
definitions for architecture, based on context:
"A formal description of a system, or a detailed plan of the
system at component level to guide its implementation.
The structure of components, their interrelationships, and the
principles and guidelines governing their design and evolution
over time."
Basic concepts of architecture:
Structure
Component
relationship
CL - architecture is necessary to do
Design and model at different levels of
abstractions
Separate specification from implementation
Build flexible systems
Make sure business requirements are
addressed
Analyze the impact of a change in requirements
Ensure principles are followed
CL – SOA definition
"Service-Oriented Architecture (SOA) is an
architectural style for creating an
enterprise IT architecture that exploits the
principles of service-orientation to achieve
a tighter relationship between the business
and the information systems that support
the business."
CL - SOA characteristics
It enhances the relationship between
enterprise architecture and the business.
It allows the building of composite
applications as a set of integrated
services.
It provides flexible business processes.
CL - SOA layered architecture
CL – WEB services (one implementation of services)
What the Web did for program-to-user interactions,
Web Services are poised to do for program to program
interactions.
common program-to-program communications model,
built on existing and emerging standards:
HTTP
XML
Simple Object Access Protocol (SOAP)
Web Services Description Language (WSDL)
Universal Description,
Discovery and Integration (UDDI).
CL - Definition of Web Services
A Web service is an interface that describes a collection of
operations that are network accessible through standardized XML
messaging
A Web service is described using a standard, formal XML notion,
called its service description
It covers all the details necessary to interact with the service,
including message formats (that detail the operations), transport
protocols and location
The interface hides the implementation details of the service,
allowing it to be used independently of the hardware or software
platform
It allows loosely coupled, component-oriented, cross-technology
implementations
CL - The Web Services Model
CL - Roles in a Web Services Archit
Service provider. From a business perspective, this is the owner of
the service. From an architectural perspective, this is the platform
that hosts access to the service.
Service requestor. From a business perspective, this is the
business that requires certain functions to be satisfied. From an
architectural perspective, this is the application that is looking for
and invoking or initiating an interaction with a service. The service
requestor role can be played by a browser driven by a person or a
program without a user interface, for example another Web service.
Service registry. This is a searchable registry of service
descriptions where service providers publish their service
descriptions. Service requestors find services and obtain binding
information (in the service descriptions) for services during
development for static binding or during execution for dynamic
binding. For statically bound service requestors, the service registry
is an optional role in the architecture, because a service provider
can send the description directly to service requestors.
CL - Operations in a Web Service Archit
Publish. To be accessible, a service description needs to be
published so that the service requestor can find it. Where it is
published can vary depending upon the requirements of the
application
Find. In the find operation, the service requestor retrieves a service
description directly or queries the service registry for the type of
service required. The find operation can be involved in two different
lifecycle phases for the service requestor: at design time to retrieve
the service’s interface description for program development, and at
runtime to retrieve the service’s binding and location description for
invocation.
Bind. Eventually, a service needs to be invoked. In the bind
operation the service requestor invokes or initiates an interaction
with the service at runtime using the binding details in the service
description to locate, contact and invoke the service.
CL - Artifacts of a Web Service
Service. Where a Web service is an interface described by a
service description, its implementation is the service. A service is a
software module deployed on network accessible platforms provided
by the service provider. It exists to be invoked by or to interact with a
service requestor. It can also function as a requestor, using other
Web Services in its implementation.
Service Description. This includes its data types, operations,
binding information and network location. It could also include
categorization and other metadata to facilitate discovery and
utilization by service requestors. The service description might be
published to a service requestor or to a service registry.
CL – benefits of SOA
Greater alignment of business and IT
Component-based systems
Loosely coupled components and systems
A network-based infrastructure, enabling
geographically and technologically diverse
resources to work together
On-demand, built-on-the-fly-applications
Greater code reuse
Better process standardization throughout the
enterprise
Easier centralization of corporate control
Missing levels of SOA (in this presentation)
BL – Business level
SL - System / application level
TL - Technology / standards level
CL - Component level
ML – Mathematical / theorethical level