| Bottom | Home | Article | Bookshelf | Keyword | Author | Oxymoron |

SOA

Enterprise SOA

Service-Oriented Architecture Best Practices

Cat: ICT
Pub: 2005
#: 0817b

Dirk Karfzig, Karl Banke, and Dirk Slama

08806u/18122r

Index
  1. Introduction:
  2. An Enterprise IT Renovation Roadmap:
  3. Evolution of the Service Concept:
  4. Inventory of Distributed Computing Concepts:
  5. Service-Oriented Architecture:
  6. Services as Building Blocks:
  7. The Architectural Roadmap:
  8. SOA and Business Process Management:
  9. Managing Process Integrity:
  10. Infrastructure of the Service Bus:
  11. SOA in Action:<
  12. Motivation and Benefits:
  13. The Organizational SOA Roadmap:
  14. SOA-Driven Project management:
  1. 序:
  2. IT改造のロードマップ :
  3. サービス概念の進化:
  4. 分散コンピューティングの概念:
  5. サービス指向アーキテクチャ:
  6. ビルディングブロックとしてのサービス:
  7. アーキテクチャのロードマップ:
  8. SOAとビジネスプロセスマネジメント:
  9. マネジメントプロセスの完全性:
  10. サービスバスの基盤:
  11. SOAの実施:
  12. モチベーションと利点
  13. 組織的SOAロードマップ:
  14. SOA駆動型プロジェクトマネジメント:
Why?
  • IT is installed to furnish services; thus S of SOA (Service-Oriented Architecture) is essential.
  • ITはサービスを提供するために構築される。従ってSOAの内のSこそが重要なのである。
Résumé
Remarks

>Top 0. Introduction:

  • The SOA principles described in this book are the foundation on which enterprises can build an IT architecture that will satisfy today's most important IT requirements - agility and flexibility - at affordable cost. (Martin Frick)

0. 序:

  • 本書記載のSOAの原則は、今日のITで最も重要な、俊敏性と柔軟性を適切なコストで実現するという要求を満たすITアーキテクチャを築くための基礎となる。(Martin Frick)

>Top 1. An Enterprise IT Renovation Roadmap:

  • Agony vs. Agility:
    • Because of today's highly competitive global economy, these business processes underlie constant change: Enterprise must constantly sense changes in market conditions and swiftly adapt their strategies in reflect these changes.
    • We can normally observe an initial phase of high productivity and agility. However, the ability to make more changes to the systems deteriorates dramatically, and maintenance over time becomes harder and harder.
    • Typically, there is no time and budget for doing a proper refactoring of the system to ensure in long-term maintainability.
  • Enterprise software:
    • Enterprise software is tightly coupled with the internal organization, processes, and business model of the enterprise.
    • Business data will have a very long lifetime, especially when compared with the much shorter cycles of technology innovations.
    • The number of end users will be potentially very large, often more than 10,000.
  • SOA:
    • Service-Oriented-Architectures are particular well suited to cope with the needs of such an ongoing incremental process of optimization.
  • Requirements for enterprise software architecture:
    • It must fulfill very different requirements than a software architecture that is controlled by a small number of highly qualified domain experts, such as the Mars robot or a video game engine, which must provide particular characteristics:
      • Simplicity:
      • Flexibility and maintainability:
      • Reusability
      • Decoupling of functionality & technology:
        It must decouple the long lifecycle of the business application landscape from the shorter innovation cycles of the underlying technology. The architecture must avoid dependencies on specific products and vendors.
  • Enterprise architecture is not equal to an enterprise standard:
    • Enterprise Standards:
      Based on strict norms & specifications that are imposed globally
      • 1980s: Enterprise Data Model (EDM)
      • 1990s: Enterprise Software Bus (ESB)
    • Enterprise Architecture:
      Technology independent blueprint, which allows for local application structuring and flexible, global integration
      • 2000s: Service-Oriented Architecture:
    • SQL: largely seen as a tool for technical experts; too fine-grained and closely intertwined with technical concepts.
    • SOA: enables us to constantly compare the nominal and the actual and to react accordingly to fill the gaps.

1. IT改造のロードマップ:

  • 苦悩と俊敏性:
    • 今日の国際競争力の中で、ビジネスプロセスは常に変化を求められている。企業は常に市場条件の変化を読み取り、変化に対応できる戦略に即適応すべきである。
    • 初期段階では、高い生産性と俊敏性が見られるものの、さらなる変化への対応は劇的に劣化し、時間経過とともにその維持はますます困難になる。
    • 典型的には、長期間の保守のためのシステムを適切に修正する時間も予算もない。
  • 企業のソフトウェア:
    • 企業のソフトウェアは内部組織、プロセス、ビジネスモデルと密接に関連している。
    • ビジネスデータは、技術革新のサイクルと比べて、非常に長い寿命がある。
    • エンドユーザ数は非常に大きく、しばしば１万以上となる。
  • SOA:
    • サービス・オリエンテッド・アーキテクチャは、特に、日常的な変化に対して最適化した考えである。
  • 企業用ソフトウェアアーキテクチャの要求:
    • それは火星のロボットやビデオゲームエンジンなど少数のエキスパート用のソフトウェア・アーキテクチャとは異なる。それは以下の特徴を持つ。
      • 単純性
      • 柔軟性・保守性
      • 再利用性
      • 機能と技術の分離
        ビジネスアプリの長寿命と短期の技術革新サイクルとの分離が必須である。アーキテクチャは特定製品や特ベンダから独立しなければならない。
  • エンタープライズアーキテクチャはエンタープライズ標準とは異なる。
    • エンタープライズ標準:
      厳格な基準と仕様によるグローバル統合
      • 1980年代: エンタープライズ・データモデル(EDM)
      • 1990年代: エンタープライズ・ソフトウェアバス (ESB)
    • エンタープライズアーキテクチャ:
      技術的に独立することで、ローカルなアプリ構築し、柔軟でグローバル統合を可能にする。
      • 2000年代: SOA
    • SQL: ほとんど技術エキスポートの道具で、あまりにも粒度が細かく、技術概念と絡んでいる。
    • SOA: 標準と実際とを比較し、ギャップを埋めるべく対応することが可能となる。

>Top 2. Evolution of the Service Concept:

  • What is 'service'?:
    • a remotely accessible, self-contained application module. Application frontends are making these services accessible to human users. Here client=service consumer, and server=service provider.
  • Elements of SOA:
    • Services and Application Frontends
    • Service Repository
    • Service Bus
  • A service consists of both data and business logic along with interfaces and their descriptions such as IDL (Interface Definition Language) or WSDL (Web Service Definition Language).

2. サービス概念の進化:

  • サービスとは:
    • 遠隔でアクセスできる自己完結的なアプリケーション・モジュールである。アプリケーションフロントエンド側では人が操作する。ここでクライアント＝サービス・コンシューマ、またサーバ＝サービス・プロバイダと呼ぶ。
  • SOAの要素:
    • アプリケーション・フロントエンド
    • サービス・レポジトリィ
    • サービス・バス
  • サービスはデータ、ビジネスロジック、インターフェースおよびその記述（IDLやWSDL）から成る。
  • >Top Long history of programming language, distribution technology and business computing:

evolution_ser_concept
  • Remarks:
    • ADA=object oriented high-level language; named after Ada Lovelace, the first computer programmer.
    • SIMULA: object-oriented programming language developed by Norway in 1960s, a superset of Algol 60.
    • DWH=Data Warehouse (late 190s); includes BI tools, tools to extract, transform, and load data into the repository; data-consistent top-down model, and fast-turnaround time bottom-up model.
    • R/3=SAP R/3, client-server version (1992 by SAP)
    • NFS=Network File System (1984 by Sun)
    • CORBA=Common Object Request Broker Architecture (1991 by OMG)
    • DCOM=Distributed Component Object Model (1995 by MS)
    • EAI = Enterprise Application Integration
    • EJB=Enterprise Java Beans (1997 by Sun)
    • MQ=Message Queuing (1992 by IBM)
    • MDA=Model Driven Architecture (2001 by OMG)
    • SOAP=Simple Object Access Protocol (2003 by W3C)
    • WSDL=Web Services Development Language (2001 by W3C)

>Top 3. Inventory of Distributed Computing Concepts:

  • Heterogeneity of Communication Mechanism:
    • Communication mode:
      • synchronous and asynchronous mechanism
    • Products: 　
    • Additional runtime features:
      • security, fault tolerance, load balancing, transaction handling, logging, usage metering, and auditing
  • Communication Middleware:
    • Communication infrastructures encapsulated the technical complexity of such low-level communication mechanisms by insulating the application developer from the details of the technical base of the communication
  • Remote Procedure Calls (RPC):
    • RPCs apply the concept of the local procedure call to distributed applications.
    • driven by Sun Microsystems in mid 1980s (NFS)
    • standardized DCE (Distributed Computing Environment)
  • Distributed Objects:
    • In the early 1990s, the concept of Distributed Objects was invented to make this new programming paradigm available to developers of disputed applications.
    • The most common ORB (Object Request Broker) implementations are CORBA (multiple platforms), COM/DCOM (Microsoft platform), and RMI (Java platform).
    • Secretariat systems are more data-centric; they produce fewer remote calls with a heavier payload and more simple interaction patterns.
    • ORBORB (Object Request Broker):
      An ORB can be used as a communication infrastructure for the implementation of an SOA
  • Message-Oriented Middleware (MOM):
    • Key component: message and queue
    • MOM encourages loose coupling between message consumers and message producer, enabling dynamic, reliable, flexible, high-performance systems to be built. However, one should not underestimate the underlying complexity.
  • Transaction monitors:
    • Popular examples of transaction monitors are CICS (Customer Information Control System), IMS (Information management System), Encina, or Tuxedo, which all provide facilities for remote access.
  • Application servers:
    • The basic functions of an application server can be described as hosting components, managing connectivity to data sources, and supporting different types of user interfaces, such as thin Web interfaces or fat client applications.
  • Synchrony:
    • Synchronous communication is characterized by the immediate responses of the communication partners. The communication follows a request/reply pattern the enables the free flow of conversation, often based on the use of busy waits.
    • Asynchronous communication is less stringent.
    • Typically, synchronous communication is implemented by RPC-style communication infrastructures, while a asynchronous mechanisms are implemented by MOM.
  • Common ways of implementing synchronous and asynchronous communication with both RPC/ORB and MOM technology:
    • Simulated synchronous services with queues
    • Asynchronous one-way: fire-and forget RPC
    • Callbacks and polling services.
  • Tight vs. Loose Coupling:
    • Traditionally, business processes have been designed within the boundaries of an enterprise, or even within the different business units of the enterprise. These activities were managed with the help of detailed, real-time information. In these kinds of scenarios, one sees a much higher degree of uncertainty, a much more frequent change in terms of participants and their roles, and a constant evolution of the types of interactions required.
    • Using loose coupling makes the application landscape more agile, enables quicker change, and reduces risk. In addition, system maintenance becomes much easier.
    • Loose coupling becomes particularly important in the B2B world, where business partners often change rapidly.

3. 分散コンピューティングの概念：

  • 通信メカニズムの混在:
    • 通信モード:
    • 製品:
    • 実行時の追加機能:
  • 通信ミドルウェア:
    • 下位レベルの通信メカニズムに煩雑さを通信基盤が隠す
  • RPC:
    • ローカル・プロシージャ・コールの概念を分散アプリケーションに適用
    • NFS (Sun Microsystems)
    • DCEによる標準化
  • 分散オブジェクト：
    • 1990年代初、分散オブジェクトの概念が導入され、分散アプリケーションの開発に活用された。
    • 有名はORBとしては、CORBA (汎用), COM/DCOM (Microsoft), RMI (Java)がある。
    • ORB (概念図は左図):
  • リモートプロシージャ(RPC):
    • RPCによって分散プロシージャコールの概念を導入
    • NFS: Sunが1980年代に導入
    • その後、DCEとして標準化
  • MOM:
    • キーは、メッセージとキュー
    • メッセージ受信者とメッセージ生成者とを疎結合することで、ダイナミックで信頼性、柔軟性があり、パフォーマンスの高いシステム構築できる。但し、必要な複雑さは軽視できない。
  • トランザクション・モニタ:
    • 一般的な例としては、CICS, IMS, Encina,Tuxedoなどがあり、いずれもリモートアクセスを容易にする。
  • アプリケーション・サーバ:
    • このアプリケーション・サーバの基本機能は、ホスティングコンポーネントや、データソースへの接続を管理し、ユーザインタフェースをサポートする（軽いWebインターフェスや重たいクライアントアプリケーションなど）
  • 同期性:
    • 同期通信は、通信相手からの瞬時を応答を受けるのが特徴である。その通信はリクエスト／リプライ・パターンに従って、ビジーウエイトという方法によって自由な通信フローが可能となる。
    • 非同期通信は、もう少し緩やかなものである。
    • 典型的には、同期通信はRPCで、また非同期通信はMOMによって実現される。
  • ROC/ORBとMOMを利用した同期通信と非同期通信の実装例:
    • キューによる疑似同期サービス
    • 非同期一方向の撃ち放しRPC
    • コールバックとポーリングサービス
  • 密結合対疎結合:
    • 伝統的なビジネスプロセスは、企業という境界線の内側だけで設計されており、あるいはある事業部門内のみで管理されていた。これらの活動は、詳細なリアルタイムの情報で管理されていた。このシナリオでは、不確実性の度合いが非常に高く、参加者とその役割の変更も多く、必要なやりとりも常に変化している。
    • 疎結合を使うことで、アプリケーションの状況は、迅速に変更でき、リスクを低減することができる。さらに、システム維持も容易になる。ビジネスエンティティが独立したやり取りをしなければならないB2Bの分野では、ビジネスパートナーとの関係は頻繁に変更されるので、疎結合は非常に重要である。
  • >Top Tight vs. Loose Coupling:
Level
Tight Coupling
Loose Coupling

Physical coupling

Direct physical link required Physical intermediary
Communication style Synchronous Asynchronous
Type version Strong type system (Eg: interface semantics) Weak type system (Eg: payload semantics)
Interaction pattern OO-style navigator of complex object trees Data-centric, self-contained messages
Control of process logic Central control of process logic Distributed logic components
Service discovery & binding Statically bound services

Distributed logic components
Platform dependencies Strong OS and programming language dependencies. OS-and programming language independent.

>Top 4. Service-Oriented Architectures:

4. サービス指向アーキテクチャ:

>Top 5. Service as Building Blocks:

  • The focus of a SOA is on the functional infrastructure and its business services, not the technical infrastructure and its technical services. A business-oriented service in an SOA is typically concerned with one major aspect of the business, be it a business entity, a business function, or a business process.
    • An important feature of a software architecture is that it breaks down the overall structure of a software system into smaller components. These components are intended to be flexible building blocks.
  • Classification:
    • Application frontends:
      They initiate all business processes and ultimately receive their results. (GUI or batch process)
    • Basic services:
      They represent the basic elements of the vertical domain.
    • Intermediary services:
      They cut into technology gateways, adapters, facades, and functionality-adding services. Unlike process centric services they are stateless.
    • Process centric services:
      The encapsulate the knowledge of the organization's business processes., maintain the process state.
    • Public enterprise services:
      They provide interfaces for cross-enterprise integration, providing decoupling, security, billing, or robustness.

5. ビルディングブロックとしてのサービス:

  • SOAが焦点を当てているのは、機能基盤とそのビジネスサービスであり、技術基盤や技術サービスではない。SOAのおけるビジネス指向のサービスは、特にビジネスの主要な側面に関与している、即ち、ビジネスエンティティ、ビジネス機能、そしてビジネスプロセスである。
    • ソフトウェアアーキテクチャの特徴の一つは、ソフトウェアシステム全体の好悪図をより小さな構成要素に分割できることにある。これらは柔軟なビルディング・ブロックとなる。
  • 分類:
    • アプリケーションフロントエンド:
      すべてのビジネスプロセスを起動し、最後にその実行結果を受け取る。 (GUIやバッチ)
    • 基本サービス:
      垂直でメインにおける基本要素である。
    • 中継サービス:
      技術ゲートウェイ、アダプタ、ファサード(外観)、付加機能、サービスに分けられる。これはプロセス状態を保持しない。
    • プロセス中心サービス:
      組織委のビジネスプロセスのナレッジをカプセル化する。プロセスの状態を保持する。
    • 公開エンタープライズサービス:
      企業間取引の為のインターフェイスの提供。分離、セキュリティ、課金、堅牢性などを提供する。
  Basic services Intermediary Services Process-Centric Services Public Enterprises Services

Description

 Simple data-centric or logic-centric services Technology gateways, adapters, facades, and functionality-adding services Encapsulate process logic Serve shared with other enterprises or partner organizations
Implementation Complexity Low to moderate Moderate to high High Service specific
State Management Stateless Stateless Stateful Service specific
Reusability High Low Low High
frequency of Change Low Moderate to high High Low
Mandatory Element of SOA Yes No No No

>Top 6. The Architectural Roadmap:

maturationof_soa

  • The maturation of the SOA with respect to the expansion stages often correlates to an enlargement of the scope of business integration
    • When deciding on your SOA strategy, you should always ask yourself how much agility do you really need? Also consider the learning curve in your organization. Are you fit for process-enabled services? Choose an SOA strategy that best matches your agility requirements, your integration scenario, your architectural and developmental skill, and obviously your budget constraints.
  • lifecycleof_appli
  • The typical lifecycle of an enterprise application traverses different development stage.
  • Process-Enabled SOA:
    • The third expansion stage if the fully leveraged SOA. The key feature of the process-enables SOA is the maintenance of process stage in process-centric services.
    • Similar to intermediary services, a process-centric service is both client and server in an SOA. The major difference between these service types is the fact that process-centric services are stateful;. This is a crucial difference because handling state is a critical issue for server-side software.
    • There are several possible reasons for introducing a process-centric service;
      • Encapsulating the complexity of processes
      • Sharing state between multiple clients
      • Handling long-living processes

6. アーキテクチャのロードマップ:

  • 拡張段階に応じたSOAの成熟度とビジネス統合の範囲の大きさには相関関係がある。 (左図)
    • SOA戦略を決定する時には、どの程度の俊敏性が必要ななのか。また組織内の学習曲線も考慮すべきである。本当にプロセス制御段階のサービスが必要なのか、求められる俊敏性、統合シナリオ、アーキテクチャ設計と開発スキル、さらに予算上の制約も考慮してSOA 戦略を選択すべきである。
  • エンタープラズ・アプリの典型的なライフサイクルにおけるそれぞれの発展段階 (左図)
    • 1986頃：チェックイン・アプリ往生
    • 提携航空会社との提携
    • 顧客向け予約ポータルの開始
    • SOA導入
    • チェックイン・アプリのGUI対応
    • モバイル対応チェックイン・アプリのモバイル対応
  • 第３段階はSOA：
    SOA が十分活用される段階。プロセス制御段階のSOAの重要な特徴は、プロセス中心サービスにおけるプロセス状態の保持である。
    • 中継サービスと同様に、プロセス中心サービスはSOAでクライアントとサーバの両方の役割を果たす。状態を処理するかどうかは、サーバ側のソフトでは非常に重要なので、これは決定的な違いである。
    • プロセス中心サーバを導入導入するメリットは以下の３つである。
      • プロセスの複雑性をカプセル化する
      • 複数クライアントによる状態の共有
      • 長寿命のプロセスの処理

>Top 7. SOA and Business Process Management:

  • BPM has a number of predecessors:
    • late 1980s: TQM
    • early 1990s: BPR
    • 1993: "Reengineering the Corporation" published by Michael Hammer and James Champy
    • "BPM; The Third Wave" by Howard Smith and Peter Fingar; recommends incremental change and evolutionary optimization.
  • BPMS (Business Process Management System): provides the technical platform for realizing BPM management initiatives.
    • IT and business must work hand-in-hand.
    • Utilize process templates.
    • Mach the right technology to your problem.
    • Adopt the development model.
  • BPM_archiOverview of a BPM System:
    • Modeling languages:
    • BPMN (BP Modeling Notation)
    • Many similarities exist between UML activity diagrams and BPMN.
  • The BPM vision:
    is a strong one - instead of hard-coding information and rules regarding important business processes directly in the application code, we think this information out of the application systems and put it under the control of a BPM system.
  • Data & functions vs. Objects vs. Services:
    • Functional programming:
      data and functionality ware strictly separated.
    • Object orientation:
      began to merge data and functionality into encapsulated, reusable object implementation. This worked well for large, monolithic applications. (CORBA, etc.)
    • SOA:
      Due to the complicated interaction patterns that result form the fine-grained nature of distributed objects, the reuse of distributed objects because increasingly complex. With SOAs, toward less complex, relatively coarse-grained, loosely coupled (c.e., less dependent) component interfaces.

7. SOAとビジネスプロセスマネジメント:

  • BPMの歴史
    • 1980年代後半：TQM
    • 1990年代前半：BPR
    • 1993年："リエンジニアリング革命"
    • "BPM：第三の波"：ゼロからの作り直しではなく、段階的変化による最適化
  • BPMSは、BPMを実現するための技術基盤を提供するもの。
    • ITとビジネスは共に機能する
    • プロセステンプレートの活用
    • 問題に対する正しい技術の適用
    • 開発モデルの適用
  • BPMSの概略 (左図)
    • モデリング言語：BPMN (BP Modeling Notation) ；BPMI (BP Management Initiative)によって規定
    • UMLのActivity図とBPMNには共通点あり
  • BPMのビジョン:
    • 重要なビジネスプロセスに関する情報ルールをアプリコードに直接コーディングする代わりに、アプリシステムの外側に記載し、BPMシステムの制御下に置く。
  • データと機能 対 オブジェクト 対 サービス:
    • 関数型プログラミング：
      データと機能は厳格に分離
    • オブジェクト指向：
      データと機能を会わせたカプセル化され再利用可能なオブジェクトが登場し、モノリシックアプリに有利 (CORBAなど)
    • SOA:
      粒度が細かく、かつ依存性の高い分散オブジェクトから離れ、粒度の大きい疎結合のコンポーネントインタフェースを目指す。

>Top 8. Managing Process Integrity:

  • Data Integrity:
    • Data integrity is an umbrella term that refers to the consistency, accuracy, and correctness of data.
    • The classical mechanisms are often closely tied to the concepts of relational databases. It includes entity, domain and referential integrity.
      • Entity integrity:
        each row in the table be uniquely identified.
      • Domain integrity:
        a set of data values fall within a specific range (domain).
      • Referential integrity:
        Validity of relationships between different data tulles.
  • Process Integrity:
    • This is beyond the issues of traditional data consistency. We are not dealing with short-lived updates of data contained in a central repository, but instead with long-lived processes that cross multiple systems.
    • there will be time intervals where the internal systems reflect cancellation: a process inconsistency.
  • ACID Transactions:
    • Traditionally, the term transaction has been used to describe a unit of work in an OLTP system or database that transforms data from one stage to another.
    • ACID has been coined to describe the ideal characteristics of concurrently executed and possibly distributed transactions, which ensure the highest level of data integrity.
      • Atomicity:
        ACID transactions are atomic "all or nothing" units of work.
      • Consistency:
        ACID transactions transform data from one consistent state to another. Of particular importance is the stipulation that a transaction ensures referential integrity.
      • Isolation:
        The internal state of a running transaction is never visible top any other transaction.
      • Durability:
        Committed updates of a transaction are permanent.
  • Two-Phase Commit Protocol (2PC):
  • 2PC
    • A client begins a new transaction (1), executes tow updates (2&3), and attempts to commit the changes (4).
    • The transaction coordinator sends prepare requests to both resource managers (5).
    • The final step of the transaction (6) either commits or aborts all updates.
    • If both resource managers agree to commit the transaction, the transaction coordinator sends a commit to all participants.
    • If one participant wants to abort, the transaction coordinator asks all participants to abort.
  • Transaction Processing Monitors (TPMs):
    • Well-established transaction monitors include CICS, IMS, Encina (IBM), and Tuxedo (BEA)
  • Combine transaction chains with compensating transactions:
    • ACID properties are usually too strong for complex workflows. Instead, chained transactions with compensating transactions offer a viable means of dealing with process integrity.
      • Transaction chains combine individual transactional steps into more complex workflows.
      • Compensating transactions undo previously executed steps if a problem is encountered during the execution of a particular step in a transaction chain.
  • Model of Concurrency control:
    • Pessimistic concurrency control:
      This model give users exclusive access rights to a set of data that they intend to modify, usually through the acquisition of a lock, which is associated with the data in question. Other users are locked out.
    • Optimistic concurrency control: (for long-running transactions; the model of choice in an SOA)
      In this model, no locks are acquired during the transaction execution. This control permits different transaction to read the same state concurrently and checks for potential write conflicts and data inconsistencies only at the end of the transaction, when changes are actually written to the database.

8. マネジメントプロセスの完全性:

  • データの完全性:
    • データの完全性は、データの一貫性、精密性、正確性を包括する用語である
    • 古典的メカニズムとしては、RDBの概念。それはエンティティの完全性、ドメインの完全性、参照の完全性を含む
      • エンティティの完全性:
        テーブルの各行は、ユニークに識別されなければならない。
      • ドメインの完全性:
        あるデータセットは、ある特定の範囲(ドメイン) に含まれなければならない。
      • 参照の完全性:
        異なるデータの組間での関係の正当性
  • プロセスの完全性:
    • これは伝統的なデータの一貫性の問題とは大きく異なる。中央リポジトリに格納したデータを短時間で更新するような処理ではなく、複数システムをまたがる
    • 長時間処理のプロセスを扱う。
    • キャンセルの場合など：事業部間や企業間ではデータの不一致が生じる。
  • ACID トランザクション:
    • トランザクションとは、伝統的に、OLTP システムやデータベースでの作業単位をいい、データをある状態から他の状態に遷移させること。
    • ACIDは、同時実行でき分散状態にもなり得るトランザクションの理想的な性質を表す 。
      • 原子性:
        最小作業は原子のようにAll or nothingの性質をもつ。
      • 一貫性:
        データをある一貫性のある状態から他の状態へ遷移させる。重要なことは、トランザクションは参照の完全性を保証しなければならない。
      • 孤立性:
        実行中のトランザクションの内部状態は他のトランザクションからは決して見えない。
      • 永続性:
        トランザクションでコミットした更新は永続的なものである。
  • 二相コミットプロトコル (2PC):左図
    • まずクライアントがトランザクションを開始(1)
    • ２つの更新を実行(2,3)
    • 変更のコミット要請(4)
    • プリペアリクエストの送信(5)
    • すべての更新のコミットか中止かを行う(6)
  • トランザクション処理モニタ (TPM):
    • CICS, IMS, Encina (IBM), Tuxedo (BEA)
    • JTS (Java), MTS (MS)
  • トランザクションチェーンと補償トランザクションの結合:
    • ACID特性は、複雑なワークフローに対しては厳しすぎる。それに代わって、トランザクションチェーンと補償トランザクションの組み合わせは、プロセスの完全性を取り扱う上で有効と言える。
    • トランザクションチェーンは、個々のトランザクションのステップをより複雑なワークフローに結合する
    • 補償トランザクションんは、あるステップの実行で問題が発生すると、前に事項されたステップを取り消す。
  • 並行制御のモデル:
    • 悲観的並行制御:
      このモデルは、ロックによってデーアセットに対する排他的アクセス権をユーザに与える。その間、他のユーザは閉め出される。
    • 楽観的並行制御: (長寿命トランザクション向き、SOA向き)
      このモデルは、トランザクション実行中にロックはしない。異なるトランザクションが同じ状態を同時に読むことを許可し、トランザクションの最後に実際にデータベースへの変更が書き込まれる時だけ、書き込みが矛盾しないか、データ不一致がないかチェックする。

>Top 9. Infrastructure of the Service Bus:

  • Software buses:
    • Much as a hardware bus enables the integration of hardware parts from different vendors; software bus is the standardized way of hooking together any software component.
    • OMG's CORBA: a matured technology; leans itself to a very fine-grained communication infrastructure.
    • In a real enterprise application landscape, a single communication model will hardly suffice:
    • J2EE environment supports various communication types:
      • EJB (Enterprise JavaBeans) supports synchronous object-oriented communication
      • Java Message Service (JMS) provides messaging
      • the system supports communication using email, SOAP
      • Service specification provides general support for HTTP application
  • Software bus that supports various communication models at the same time, such as synchronous, asynchronous, or file-based communication.
  • Meta Bus:
    • Plan for a service bus on a meta level that supports technical services at a higher level and adds flexibility that can be critical for the business during acquisitions or major restructuring.

9. サービスバスの基盤:

  • ソフトウェアバス:
    • 異なるベンダのほとんどのハードウェア部品の統合が、ハードウェアバスのよってなされるように、ソフトウェアバスは各々のソフトウェア部品を組み合わせる標準的な手法である。
    • OMGのCORBA：枯れた技術だが、細かい粒度での通信インフラとしては機能不足の面あり。
    • 実際の企業では、単一の通信モデルではほとんど十分とは言えない。
    • J2EE環境では様々な通信タイプをサポートしている。
      • EJBが同期オブジェクト通信を
      • JMSがメッセージングを
      • システムがemail やSOAPを
      • サービス仕様がHTTPアプリケーションを
  • さまざまな通信モデルを同時にサポートするソフトウェアバス ；即ち、同期通信、非同期通信、ファイルベースの通信
  • メタバス:
    • より高いレベルあるいは柔軟性をもった技術サービスをメタレベルでサポートするためのサービスバスを構築すべきである。これは買収や主要リストラの際に重要となり得る。

>Top 10. SOA in Action:

  • Transformation of a monolithic application into a service-oriented application:
    • In order to provide EAI functionality in a serve-oriented environment, the most common task is service enablement. It is the process that creates a service to encapsulate the functionality provided by an existing application. The type of application encapsulated can be anything from a monolithic mainframe application to a distributed application built on top of CORBA or DCOM.
    • As the first step, the application is separated into a visual and a non-visual part. Communication between both parts is grouped based on their business domain. Access to the non-visual layer is defined by one or more interfaces. If possible, the implementation of the interfaces and the persistent data upon which they act can also be separated. Finally, the application is moved to the service infrastructure.
    • a) The starting point is a monolithic application.
    • b) The visual part is separated from the non-visual part of the application.
    • c) A vertical slicing distinguishes various interfaces.
    • d) The data model is cut into separated sub models.
    • e) The application is cut into application frontends and business services. A service infrastructure decouples the business components from the underlying distribution technology.
  • Service stability and the ability to upgrade are two of the most desirable features in an EI environment. The reason is the service consumer might reside in a different department or even in a different country form the service provider. The service provider must be able to upgrade a service without having an impact on current applications that integrate this service.

10. SOAの実施:

  • モノリシックのアプリからサービス指向アプリへ変換:
    • EAIの機能を提供するには、サービスを使用可能化する。それは既存のアプリの機能をカプセル化してサービスにするプロセスである。
  • a) 出発点はモノリシックなアプリ
  • b) アプリをビジュアル部分と非ビジュアル部分とに分割
  • c) 垂直に分断し、様々なインターフェイスに分割
  • d) データモデルをサブモデルに分割
  • e) アプリをフロントエンドとビジネスサービスとの分離。サービス基盤は、その基礎となる分散技術からビジネスコンポーネントを分離
  • サービス安定性とアップグレード容易性は、EAI環境の特性。そのりゆうは、サービス利用者がサービス提供者とは異なる部門、あるいは異なる国にあるかも知れないから。サービス提供者は、そのサービスと統合しているアプリに影響を与えることなくサービスのグレードアップが必要となる。

>Top 11. Motivation and Benefits:

  • SOA and its benefit:
    One of the primary motivating factors for using SOA is the potential increase of agility they offer. We must identify the different levels at which enterprise projects are threatened by complexity. Inevitably, complexity diminishes the enterprise's agility.
  • The following elements of complexity can be distinguished:
    1. Technology: result from yearlong efforts to capture more and more functionality
    2. Business processes: technological complexity is complexity related to business processes
    3. Business functionality: business functionality also contains conflicting elements due to different perspectives or application contexts, which adds to the overall complexity.
    4. Integration: even if the individual applications are stable and well maintained, using them in a new context and integration them with other applications is generally a complex task.
    5. maintenance: usually components must be updated regularly, such s additional functionality and new versions of software.
  • SOA achieve their simplicity:
    1. Decomposition: decompose complex systems into application frontends and services.*
    2. Appropriate granularity: the granularity of services is well suited to gain a high-level understanding of the entire system.
    3. Decoupling rom technology: can be well understood without in-depth knowledge of technology.
    4. Reuse: SOA streamlines the code base and reduces complex redundancies.
    5. Documentation: every service is well documented.

  • SOA certainly can provide tremendous advantages for the individual people involved in the enterprise architecture.
  • Different roles in an enterprise:
  • Conclusion:
    • Many enterprises adopt an SOA in order to increase agility. SOAs are seen as a means of breaking up inflexible IT infrastructures, which are usually characterized by monolithic applications.
    • The flexibility of an SOIA, its modular and decoupled development process, and in particular its potential for application reuse enable enterprise to reduce their project risks and to achieve a faster time-to-market.
    • Introducing an SOA will in general be a long-lasting process, and its beneficial effects will become apparent not all at once but steadily during this process.

11. モチベーションと利点:

  • SOA導入のメリット:
  • 複雑性の排除による俊敏性の確保
  • SOAのよる単純化の実現

  • SOA導入に当たっての企業における異なる役割の視点:
    各々にとっての利点と挑戦課題:
    • CEO
    • CIO
    • アーキテクト
    • プロマネ
    • 業務部門
    • ソフト開発者
    • 標準ソフトのベンダ

  • 結論:
  • 多くの企業は俊敏性を増加させるためにSOAを採用する。SOAはモノリシックで柔軟性に欠けるIT基盤を打破する手段と考えられる。
  • SOAの柔軟性、モジュール式で分割された開発プロセス、特に、アプリの再利用によって企業はプロジェクトリスクを逓減しつつより迅速な市場投入が実現できる。
  • SOA導入は長期的なプロセスである。その効果は一度に表れるのではなく、プロセスを提供する機関を通して着実に表れる。
  Benefits Challenges

CEO

 1) Agile strategy
2) Short-term planning: SOA enables step-by-step approaches.
3) Budget reduction: pure maintenance tasks can be reduced.
4) Technology & vendor
independence 		1) Make it happen: a clear strategy and firm commitment are needed to overcome resistance.
2) Initial overhead: it is important to allocate a sufficient budget
3) ROI consideration: must be quantified.
4) Reporting: to the board
CIO 1) Independence from technology
2) Positive role of IT Dept.
3) Cost-reduction
4) Manageable project size: SOA enables small projects.
5) Manage heterogeneity
6) Long-term renovation roadmap

1) Migration to SOA: has to be migrated towards an SOA.
2) Decoupling: existing functionality has to be decoupled
3) Change of attitude when changing to a service-oriented approach
4) Change of relationships: to suppliers must be reconsidered.

Architect

1) More attractive job
2) Disentanglement: frees from monolithic IT infrastructures
3) Loose coupling
4) Code reuse

 1) SOA adherence
2) Reuse
3) Open-minded: to amend and change SOA itself if needed.
4) Missing technical standards: technical standardization is not yet complete.
Project
manager

1) Smaller and shorter projects
2) Technology independence
3) Parallel development: decouple development
4) Reduced project risk: due to project size and limited technology dependency.
5) Easier testing and integration: because of decoupling.

1) Service-orientation
2) Potential overhead: reusability must be taken into account in the design process.
3) Program management: to cope with cross-project dependencies due to the intended reuse of services.

 

Functional
dept.		 1) Independence from technology: can focus on functional requirements.
2) Shorter time to market: can achieve a shorter time to market for new functionality.
3) Reduction of development costs: costs fro developing new functionality are significantly reduced.

1) Service orientation: business functionality has to be made available as services.
2) Reuse: this created some overhead to coordinate requirements across different depts.
3) Sharing of responsibilities: must be involved in the design process

Software
developer		 1) More attractive jobs: focus on more interesting tasks.
2) Reduction of dependency: developers can change implementations without affecting external functionality.
3) Rapid prototyping: developers can easily test approaches.
4) Better defined requirements: SOA-based development process provides better-defined requirements.
5) Simplified testing: decoupling simplify distributed testing. 		1) Respect service interfaces: this in turn requires a clear specification before coding.
2) Processes: developers have to accept rigid processes.
3) Shard responsibility: must be shared between different development teams.
4) Learning new skills: this includes the handling of distributed transactions or the assignment of the ownership of data.
Vendor
of
standard
software		 1) sell components: SOA opens up a new market segment for standard software packages.
2) Reduced integration costs: SOA components do not require high integration costs on the customer side.
3) Low entry barrier: limited scope of a single service creates sellable standard software components.
4) Provide future proof solution: customers are increasingly demanding SOA-compliant products. 		1) Customer more independent: SOA disentangles dependencies and makes enterprises independent of specific components
2) Limited secondary business: integration and migration efforts are particularly low.
3) Missing technical standards: standardization of SOA is not yet complete.

>Top 12. The Organizational SOA Roadmap:

  • Stakeholders and potential conflicts of interest:
    • CEO and the board are responsible for high-level strategic decisions.
    • Similarly, business units drive functional requirements, and we can often observe that they present IT department with conflicting requirements because their interests are not necessarily aligned.
    • CIO is often caught between their conflicting interests because investments in infrastructure are often harder to justify to business people than concrete business applications that have a measurable return on investment.
    • ROI is a major KPI (Key Performance Indicator) for the board to approve major investments.
      • The return of infrastructure investments materializes in higher process efficiency and smaller future investments.
      • IR infrastructure projects have a history of unfulfilled promises, so decision makers are very critical to any kind of return calculation.
      • Managements often tends to favor short-term benefits over long-rem investments.
    • Similarly, project managers and operation mangers can have conflicting interests. How fast the project delivers certain business functionality often measures the success of a project.
      • The TCO (Total Cost of Ownership) is largely determined by characteristics such as systems management integration, exception handling, maintainability, and CPU resource consumption.
    • Finally, "not-invented-here" syndrome.
      • A significant portion of It projects fail because they reinvent their own middleware.
  • Four pillars for success:
    • 1) Budget, 2) Project, 3) Team, 4) Buddies:
    • Although a wide variety of factors determines the success of an enterprise's SOA strategy, four main pillars for success can be highlighted; securing a budget, choosing a suitable project to start with, setting up a strong SOA tem, and finding backers and buddies.

12. 組織的SOAロードマップ:

  • ステークホルダと潜在的な利害の相反:
  • CEOと取締役会は高度な経営戦略決定
  • 事業部は機能要件の決定。事業はIT部門へ相反した要求がされることあり
  • CIOは相反する利害の板挟み。基盤投資の根拠を示すことは困難
  • ROIは取締役会が承認するKPI
    • 基盤投資は高いプロセス効率と将来の投資の節約という形で現れる
    • 過去に実現しない約束の負の歴史あり
    • 経営者は長期投資より短期の利益を好む傾向
  • 成功のための４つの柱:
    • 予算確保
    • 適切なプロジェクトの選択
    • SOA推進チーム
    • 積極的な支持者

>Top 13. SOA-driven Project Management:

  • Different project management methodologies:
    • RAD:
      James Martin's RAD (Rapid Appropriation Development), based on incremental stages.
    • Spiral Model:
      Barry Boehm developed Spiral Model, based on a set of dull development cycles that continually refine the knowledge about the final product.
    • RUP:
      IBM developed RUP (Rational Unified Process): iterative, depends heavily on visualization through UML, and uses component-based architectures.
    • DSDM (Dynamic Systems Development Method), MSF (Microsoft Solution Framework) , and Catalysis: relatively heavyweight iterative development processes.
    • XP: Manifesto for Agile Software Development issued EP (Extreme Programming), heavily relies on peer programming.
    • dX: Robert Martin's dX method.
    • CRC cards: Class-Responsibility-Collaboration.

  • We assume that the chosen approach will support iterative development, which is essential for coping with complexity and unstable requirements. The chosen methodology will tend a little bit more toward the side of the heavyweight processes.
  • Decompose complex systems:
    • A horizontal slice of a system usually presents a particular technical tier.
    • Vertical slices represent specific business use cases, such as open account in a banking Web portal.
    • When using horizontal slicing, developers with very different skills work hand-in-hand to deliver complete end-to-end slices, from application frontend to business logic to the middleware and data layer.
    • Thin thread model:
      is essentially an application of IAD (Iterative Application Development) approach.
      This is to start with a very thin slice; for example, only comprise the functionality of capturing a single string value in the application frontend, processing this information in the middle-tier, and writing it into the database.
    • in the next phase, the thread might be thickened by adding end-to-end functionality for retrieving the string value form the database and displaying it in the application frontend.
    • In a further iteration, a more complex data structure (eg; a customer record) might be handled in a similar way.
    • Most likely, the first iteration of a thread will be slow. The next iteration will be considerably faster, because all end-to-end problems will have been addressed in the first iteration.
    • Merit:
      You should implement thin threads in order to enable a project to approach many risks in a very early phase.

  • thin_threadThin Thread Model: Iterative Application Development (IAD)
    • The basic idea of the thin thread approach is t star with a very thin slice, which might only comprise the functionality of capturing a single string value in the application frontend, processing this information in the middle-tier, and wring it into the database.
    • In the next phase, the thread might be thickened by adding end-to-end functionality for retrieving the string value from the database and displaying it in the application frontend.
    • In a further iteration, amore complex data structure might be handled in a similar way.
    • You should implement thin threads in order to enable a project to approach many risks in a very early phase.
  • Testing:
    • First, load testing and functional testing must be distinguished.
    • Load testing means testing a component under a specific load for a defined time. It is crucial to judge whether the software can meet any required SLAs.
    • Functional testing means ensuring that the operational results of a software component are consistent with expectations. Function tests that execute a single call with a given set of parameters and that then compare the result of these calls with the expected result are referred to as unit tests.
    • In contrast, when a component is functionally tested with all its backbend components available, this is referred to integration testing for this component.
    • Test design is by no means easy because any functional test must be reproducible and must achieve as much coverage as possible. The danger of "testing the obvious" is real.
    • Building tests is development work in its own right and might require building dedicated software components.
    • Test must be as simple as possible to avoid the need to create a "test for the test."

13. SOA駆動型プロジェクトマネジメント:

  • 異なるプロセスマネジメント方法論；
    アプローチの重さとモデルの反復度によって分布
  • SOAプロジェクトでは、複雑性と不安定な要求を扱うので、反復型開発のアプローチを選ぶべき。また方法論はややヘビーウェイトなプロセスを扱う傾向がある。
  • 但し、SOA駆動型プロジェクトマネジメントは新たな方法論を必要としない。

  • 素直分解 対 水平分解:
    • 水平分解とは個々の技術層
    • 垂直分解はユースケース、つまりビジネス機能
    • シンスレッドモデル:
      これは本質的に反復型アプリ開発(IAD)のアプローチ。
    • まず非常に薄いスレッドから開始する。例えば、アプリフロントエンドの中でストリング値を一つ取り込み、中間層で処理し、データベースへ書き出すという機能だけで構成される場合など。
    • 次に、データベースからストリング値を取り出し、それをフロントエンドで評しするための機能が追加されスレッドが太くなる。
    • さらに反復し、例えば顧客レコードのような複雑なデータ構造を扱う。
    • 最初のスレッドの実装には時間がかかるが、次のインテグレーションはかなり早くできるようになる。
  • テスト:
    • 負荷テストと機能テストに分けるべき:
    • 負荷テストは、特定の負荷を一定時間かけてコンポーネントをテストする。SLAを満たしているか判定する。
    • 機能テストは、コンポーネントが期待通りの操作結果を出すか舗装するために行う。
    • 一連のパラメータを使って一つの呼び出しを実行し、結果を比較する機能テストを単体テストという。
    • いくつかの単体テストをつなげて、関連した連続アクションをテストすることを統合テストという。
    • テスト間にはある程度の重複がある。負荷テストツールでも結果を検証するし、単体テストツールでも負荷を増加させる機能がある。
    • テストデザインは容易ではない。既知のことだけテストすることは危険である。
    • テスト構築はそれ事態が開発作業であり、専用のソフトウェアコンポーネントの構築が必要となる。
    • テストのためのテストは避けるべきで、できる限りテストは単純にすべき
Comment
  • There is a deep chasm between rapidly changing IT and traditional business.
  • However, the concepts of EA and SOA as well as various BPM tools could bridge the chasm converging business and IT sphere, which will be an epoch making new IT era.
  • In real information society, the term of business person and IT architect would be synonymous words.
  • 急速に変化しつつあるITと伝統的なビジネスとの間のギャップは非常に大きな谷がある。
  • EAやSOAの概念、そして様々なBPMツールはこれらの谷を埋めるビジネスとITが融合する画期的なITの時代の到来を予感させる。
  • 真の情報社会では、ビジネスマンとITアーキテクトとが同義語になる時代であろう。

| Top | Home | Article | Bookshelf | Keyword | Author | Oxymoron |