Progress to Acquire MarkLogic - Learn More
BLOG ARTICLE

オペレーショナルデータハブとSOA(サービス志向アーキテクチャ)

Back to blog
03.21.2019
0 minute read
Back to blog
03.21.2019
0 minute read
Image of hubs and spokes

オペレーショナルデータハブ(ODH)は新しいアーキテクチャパターンです。そのため、エンタープライズアーキテクトは、すでに使用している、あるいは馴染みのあるこれまでの技術とアーキテクチャに対してODHがどのような位置付けにあるのか、そして、ODHがこれらのモデルに置き換わるのか、または補完するものなのかということに関心があるかと思います。

そういった比較・考察対象となるアーキテクチャモデルの一例として、SOA(サービス指向アーキテクチャ)があります。ここでは、SOAが何を目的としていたのか、そしてODHがSOAのモデルにどのように適合できるかについて、詳しく見てみましょう。

SOAの主要機能は次の2つです。

  1.  作成 – アプリケーションの目的を定義する広範なアーキテクチャモデルと、その目的達成のアプローチを作る。
  2.  定義 – 具体的な実装仕様を定義する。

何十年もの間、ソフトウェア開発においては、アプリケーションの様々な部分で特定のジョブを実行する、モジュラー型の機能要素を使用するようになっていますがプロシージャベースの開発モデルを、リモートの分散モジュールの利用へと適合させる方法を必要としていました。

そのソリューションが、古いモデルを広範かつより明確に設計されたサービスのコレクションとして再定義することでした。これにより、完全に分散配置されたソフトウェアコンポーネントを使ったアプリケーションが可能になります。このアーキテクチャをサービス指向アーキテクチャ(SOA)と呼びます。SOAは、複数のシステムのサービスを包括し完全なガバナンスを実現しながら、サービスがオープンに使用できるようになります。

SOAの目的

SOAの主要な目的は次の3つです。

  1. プロシージャやソフトウェアコンポーネントをサービスとして構成する – これらのサービスは、アプリケーションとは疎結合であるように設計します。それにより、必要なときのみ使用できるようになります。また、ソフトウェア開発者が一貫性のある方法でアプリケーションを開発できるようにするため、簡単に使用できるように設計します。
  2. 利用可能なサービスを公開するための方法を提供する – これには、機能と共に入出力(I/O)に関する要件が含まれます。開発者がアプリケーションの中に容易にサービスを組み込めるようにサービスの公開を行います。
  3. セキュリティとガバナンスの問題を避けるため、サービスの使用を制御する – SOAにおけるセキュリティは、個々のコンポーネントのセキュリティが中心となります。コンポーネントの識別、認証手順、コンポーネント間のコネクションをセキュアにするといった点です。

SOAのこれらの特性は非常に優れているように思われましたし、実際にそうです。しかしオペレーショナルデータハブ(ODH)は、これらをさらに改善します。

ODHがSOAにフィットする所とは

SOAは優れた考え方でしたが、データサイロを爆発的に増やし、データの品質とガバナンスの問題を作り出してしまいました。SOAは、オペレーショナルな相互接続性の問題解決には貢献しましたが、企業内のいたる所にデータのコピーが作られてしまい、ガバナンスに関する意図していなかった問題を引き起こしました。

ODHは、オペレーショナルな面でサイロ間のデータ統合に対して優れたメカニズムを提供し、アプリケーション統合が進むにつれて360度ビューを得ることができます。SOAは素晴らしいのですが、データの派生データを止めるためにはODHをSOAの後ろに置く必要があります。ODHは、派生データを段階的に解消できるため、アプリケーション統合のアジリティを犠牲にすることはなくなります。

ODHでは、本来のデータ中心の統合が可能になります。統合を行なうたびにアプリケーションへデータを移動配備するのではなく、多くの場合リアルタイムアプリケーションをデータのある場所に構築することができます。ODHによるデータ中心のリアルタイムでの統合は、他の方法では実現できない部門の垣根を越えたオペレーションを可能にします。

例えばグローバル投資銀行では特定のOTCデリバティブ取引のレギュレーションを記録しなければいけません。この取引は複数のトレーディングデスクデータの統合を経たあとに収集されるものです。この時点で修正が必要な取引は、後続の処理のためにタグ付けされ記録されます。

この例では、特定のタイプの上流下流の修復処理を必要とするという事実を記録し、該当する取引のタグ付けに最適なのはODHでした。全ては統合されたコンテキストに基づいて実行されます。言い換えると、取引がどこから発生した場合であっても、オペレーションはミドルで開始されるようになります。オペレーショナルな機能を持つデータ中心の統合パターンがこれを可能にしました。

詳細はこちら

ebookIntroducing the Operational Data Hubで、ODHの機能と仕様や、現在稼働している具体的な使用例などをご覧いただけます。

Kate Ranta

Kate Ranta is a Solutions Marketing Manager at MarkLogic. She is a communications and marketing professional with a focus on digital content strategy, inbound marketing, social media campaign management, SEO, and project management.

Read more by this author

Share this article

Read More

Related Posts

Like what you just read, here are a few more articles for you to check out or you can visit our blog overview page to see more.

Architect Insights

What Is a Data Platform – and Why Do You Need One?

A data platform lets you collect, process, analyze, and share data across systems of record, systems of engagement, and systems of insight.

All Blog Articles
Architect Insights

Unifying Data, Metadata, and Meaning

We’re all drowning in data. Keeping up with our data – and our understanding of it – requires using tools in new ways to unify data, metadata, and meaning.

All Blog Articles
Architect Insights

When a Knowledge Graph Isn’t Enough

A knowledge graph – a metadata structure sitting on a machine somewhere – has very interesting potential, but can’t do very much by itself. How do we put it to work?

All Blog Articles

Sign up for a Demo

Don’t waste time stitching together components. MarkLogic combines the power of a multi-model database, search, and semantic AI technology in a single platform with mastering, metadata management, government-grade security and more.

Request a Demo