SOA

Document Sample
SOA Powered By Docstoc
					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 (<condition involving Facts>) then <Actions>
      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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:24
posted:12/8/2011
language:English
pages:41