Service Oriented Architecture overview by Alar Krist, nov 2006

1
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_arch
  itecture
• http//www-128.ibm.com/developerworks/webservices/
  library/ws-soa-term1/index.html?cadrs-
• http//www-128.ibm.com/developerworks/webservices/
  newto/
• ...

2
Service Oriented Architecture levels

• SL - System / application level
• TL - Technology / standards level
• CL - Component level

3
SL - Main model of system level SOA
4
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

5
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

6
SL - Description of SOA metadata mgmnt
7
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).

8
TL - Technology level of SOA
9
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)

10
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).

11
TL - Main concepts of WOA
12
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.

13
TL - Strategic Imperative Move business
volatility into data, and move technology
stability into code.
14
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

15
TL Important standards of SOA
16
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)

17
TL - Enterprise Service Bus
WSIF platform independent interface
In Memory
REST
JCA
COM
SOAP
Core Features of an ESB Virtualizes services
Connectsadapters, web services
Transportsover JMS, HTTP
Routesbased on content/header
Translatesprotocols formats
18
TL ESB Pattern Summary

• Point To Point
• Adapter -gt Transformation -gt 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

19
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.

20
TL - BPEL, The Orchestrator
?
21
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
• Often generated by GUI programs
• Rules executed on Rules Engines
• Facts are input
• Facts analyzed per Rules
• Actions conditionally executed or results returned

RulesEngine
results
Application
22
TL - Rules Features dynamic Fact Generation

• Rules are conceptually simple
• Facts Data concerning the world
• Rules if (ltcondition involving Factsgt) then
  ltActionsgt
• Actions Simple returns or direct action calls
• Example If (quantity gt 12) then give 20
  discount
• An action can be the generation of a new fact
• This is called inferencing
• Example If (GPA gt 3.5 and SAT gt 1400)
  then create scholarship-eligible Fact

RulesEngine
23
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
• Rules can call actions directly
• Procedural logic asserts facts to Rules engine
• Rules engine calls actions directly
• Especially attractive for notifications
• Can access database info, etc.

Claim
RulesEngine
facts
Don'tpay
ApplicationLogic
fraudalert
24
TL Appl Dev Framework model
25
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

26
TL Example Oracle SAO suite
Web Services Manager
BAM
JDeveloper Integrated Services Environment
Monitoring
Events
Analytics
BPEL Process Manager
NativeBPEL
Human Workflow
Business Rules
Enterprise Service Bus
App Dev Framework
Routing
Adapters
Security
XSLT Transform
Application Server J2EE, WS-, Event Services
UDDIRegistry
B2B
27
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

28
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

29
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

30
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

31
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."

32
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.

33
CL - SOA layered architecture
34
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).

35
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

36
CL - The Web Services Model
37
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.

38
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 services interface description for program
  development, and at runtime to retrieve the
  services 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.

39
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.

40
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

41
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