SOAのパフォーマンスのためのデータ層キャッシング

Kiran Dattani、Milind Pandit、Markus Zirn


データ・サービスで高パフォーマンスを実現

Enterprise Solution Cookbookシリーズ


2010年2月公開

ダウンロード
Oracle Fusion Middleware
Oracle Coherence

はじめに

サービス指向アーキテクチャ（SOA）により、アプリケーションの開発と統合の状況は変化しています。 Webサービス標準によって、ビジネス・ロジックに実装されている特定のテクノロジーには関係なく、既存のビジネス・ロジックをはるかに容易に再利用する ことが可能になります。 また、BPELやその他のオーケストレーション標準によって、複合プロセス・フローを通して、このようなサービスを統合することが容易になります。 そのため、SOAでは、情報にアクセスする手段だけでなく、情報をより容易に結合するための方法が提供されます。

これにより、大きな利点が得られます。特に、既存のモノリシック・アプリケーション全体にわたる相互運用性の向上により、俊敏性が改善し、生産性が 向上します。 同時に、ビジネス・ユーザーの期待が高まるため、SOAによってITのレベルも引き上げられます。 今ではコンシューマ・インターネット・アプリケーションや、Google、Yahoo、その他の企業のマッシュアップの使用に精通したビジネス・ユーザー は、エンタープライズ・システムにも同様の機能を要求するようになっています。 SOAは、このようなマッシュアップの実装に役立ちます。

この積極的な開発のマイナス面はパフォーマンスです。 パフォーマンスとスケーラビリティの問題は、SOAアプリケーションを構築する場合のもっとも大きな問題の1つになってきました。 この問題は、意外なことではありません。 SOA複合アプリケーションの結果はユーザー・インタフェースに表示されるため、許容可能な応答時間による制約を受けます。 ユーザーは通常、5秒を超える結果をすべて、単純に使用不可と見なします。 オンライン小売りでの調査によると、買い物客は、応答時間がわずか1秒を超えただけでも去ることが示されています。 SOAでは詳細なXML（Extensible Markup Language）形式を使用しており、Webサービスが呼び出されたときにデータが変換（マーシャリングおよびアンマーシャリング）されるため、オー バーヘッドが発生します。 この抽象化のために、SOAアプリケーションのパフォーマンスが低下します。

ビジネス・プロセス内のサービスが増えれば増えるほど、そのビジネス・プロセスは脆弱になります。 あるビジネス・プロセスが6つのデータ・サービスに依存し、各サービスが99%のアップタイムを達成している場合、そのビジネス・プロセス自体の停止時間 は最大6%になります。 これは、1年につき525時間もの計画外停止時間に相当します。 問題はこれだけではありません。 データ・サービスはデータ・アクセスの集中化のために設計されているにもかかわらず、多数のビジネス・プロセスが一連の同じデータ・サービスに依存してい る場合は、スケーラビリティの問題が発生します。 その上、ITで厳しい品質保証契約（SLA）を満たすことが要求されている場合は、すべてのRASPレベルで実行されるSOAアプリケーションを構築する ことが極めて重要になります。 しかし、データ層にスケーラブルなデータ・アクセス・ストアを構築するための最善の方法は何でしょうか。 ユーザー・アプリケーションを有効にし、次にビジネス・プロセスを有効にして、従来データベースに格納されているデータにすばやくアクセスするための最善 の方法は何でしょうか。

この記事では、中間層キャッシング戦略によって、SOAの一部としてのデータ・サービスで高パフォーマンスを実現する方法について説明します。 また、大手製薬会社が、Oracle Coherence GridソリューションをOracle SOA Suiteとともに使用して複合アプリケーションのパフォーマンスを向上させるために取ったアプローチも示します。

SOAのキャッシング戦略

どのSOAアプリケーションのパフォーマンスも、基礎となるデータを取得するためにかかる時間に直接比例します。 SOA内のデータは一般に、次の2つのカテゴリのどちらかに含まれます。

  • サービス・ステート - このデータは、ビジネス・プロセス/サービスの現在の状態（つまり、現在のプロセス・インスタンスはこの時点でどこに存在するか、各プロセスはアクティブ な状態、閉じた状態、中止された状態のどれかなど）に関係しています。 このデータは長時間実行されるビジネス・プロセスに特に有効であり、通常、マシンの障害からの分離を可能にするためにデータベースに格納されます。
  • サービス結果 - このデータは、ビジネス・プロセス/データ・サービスからプレゼンテーション層に戻されます。 通常、このデータは永続的であり、バックエンド・データベースやデータウェアハウスに格納されます。

キャッシングは、サービス・ステートやサービス結果のデータにアクセスする速度を向上させるうえで非常に重要な役割を果たすことができます。 キャッシングは、キャッシュを使用するサービスと、基礎となるデータ・プロバイダの間のトラフィックや待機時間の量を最小限に抑えるために使用されます。 すべてのキャッシング・ソリューションに共通する点として、ビジネス・サービスのためのキャッシング設計では、キャッシュ・データをどのような頻度で更新 する必要があるか、データがユーザー固有かアプリケーション全体に及ぶか、キャッシュの更新が必要なことを示すのにどのようなメカニズムを使用するかなど の問題を検討する必要があります。

サービス・ステートとサービス結果の両方の種類のデータをキャッシュできます。

  • サービス・ステート・キャッシュを使用すると、メモリ内にあるビジネス・プロセス内のサービス間でサービ ス・ステート・データを共有できます。
  • サービス結果キャッシュを使用すると、頻繁にアクセスされるビジネス・サービスまたはデータ・サービスか らの結果をキャッシュできます。
図1： SOA複合アプリケーションは、データ・サービスやビジネス・サービスの
データのキャッシングによってパフォーマンス向上が可能


図2は、2つのレイヤーでキャッシングを実装することによって、複合SOAアプリケーションのパフォーマンスが向上するように設計する 方法を示しています。

  • 上のキャッシュ・レイヤーは、ビジネス・サービス・ステートとビジネス・サービス結果（つまり、データ・サービス・レイヤーからの結果）の両 方をキャッシュします。
  • 下のキャッシュ・レイヤーはさらに、データ・サービス・ステート（必要な場合）と、基礎となるデータベースやアプリケーションから来るアプリ ケーション・データの両方をキャッシュします。

これがデータ・サービスのレイヤーに対してどのように機能するかを理解しましょう。 この考え方は、データソースへのアクセスの直前にキャッシュ・アクセスを追加するものです。つまり、キャッシュ・ヒットが存在する場合は条件に応じてデー タソースへのアクセスを省略し、データソースにアクセスした後はキャッシュの更新を追加します。 サービスが初めて呼び出されたときは、その結果がキャッシュされるとともに、コンシューマに提供されます。 以降の呼出しでは、アプリケーション・ロジックは最初にキャッシュを参照し、データが使用可能な場合はそこからデータを直接取得します。 このテクニックはキャッシュアサイドと呼ばれます。

図2： キャッシュアサイド・アーキテクチャはコストの高いデータベース・アクセスを回避できる


データが中間層のメモリ内に配置されるようになるため、データ・アクセスがはるかに高速になり、よりインテリジェントなサービスとより高速な応答時間が可 能になります。 このおもな目的は、基本的にパフォーマンスを低下させるデータベース・アクセスをできるだけ多く回避することです。これには、"この情報はリアルタイムで ある必要がありますか、またはほぼリアルタイムで十分ですか"という質問を行います。 短時間内のサービスへの複数の呼出しに対して同じ結果が返される可能性がある場合は、要件をキャッシュから提供されるほぼリアルタイムのデータに緩和する と、大幅なパフォーマンス向上が得られます。

キャッシュアサイドは、おもに複数の異なるバックエンド・ソースからデータを読み取るSOAアプリケーション専用の、パフォーマンス向上のための重 要な戦略です。 標準的なシナリオとして、複数のデータ・ストアにわたる顧客の360度のビューの組立てがあります。

キャッシュアサイドは、たとえば、予約データがキャッシュ内にほぼリアルタイムに格納される旅行業界で一般的です。 ホテルの宿泊や飛行機の座席をブラウジングしている誰かのすべてのインスタンスにデータベース・アクセスを許可すると、スケーラビリティの問題につながり ます。 時には、これにより、検索するたびに料金が発生するサード・パーティのシステムでの検索が必要になる場合さえあります。 そのため、旅行のためのほとんどのブラウジングは、キャッシュから提供されるほぼリアルタイムのデータで行われます。 SOAアプリケーションの高速化にも、同じテクニックを使用できます。

360度の顧客ビューの提供

非常に大規模な、研究開発指向型の製薬会社が、複数のデータ・ストアに顧客情報が分散するという問題を抱えていました。 ビジネス面での対象地域の拡大、合併や買収を通して、バックエンド・システムが追加されていました。 顧客情報は、複数のトランザクションCRMおよびERPシステム、マスター・データ管理ストア、さらにはビジネス・インテリジェンス・データウェアハウス に存在していました。 この環境によって、顧客との過去のインタラクションから入手可能なすべての情報が反映されたビューである、特定の顧客の360度のビューを提供することが 困難になりました。 その結果、この会社の営業チームは常に、顧客（つまり、医師）に関する最新の情報を入手することの困難に直面していました。 任意の特定の医師についての、複数のデータソースにわたる情報のリストの集約とフィルタリングが大きな課題として提起されました。

この問題をさらに悪化させたのは、販売担当者が、どこからでも顧客情報にリアルタイムにアクセスできる必要があることでした。 販売担当者がある医師に話をしていて、その医師の専門分野、研究、および購入パターンに基づいて新しい製品を推奨する必要があるというシナリオを考えてみ てください。 この情報がなければ、会話の質だけでなく、アップセルやクロスセルの機会も妨げられる可能性があります。 そのため、新しいソリューションでは、営業チームにモバイル機器でのリアルタイムの操作性を提供することが必要でした。

この製薬会社は、医療プロジェクト管理（HCPM）、プライマリ・ケア・ケース管理（PCCM）、およびマーケティング/キャンペーン管理アプリ ケーション（UNICA）や、CRM（Siebel）、財務（Oracle E-Business Suite）、マスター・データ管理（Siperian）、その他の複数のデータソースにわたって顧客を正常に検索するには、マルチチャネルのSOAおよ びWeb 2.0ベースのソリューション・プレゼンテーション・レイヤーを使用して医療サービス・プロバイダの360度のビューを提供するための、俊敏かつ完全に構 成可能なデータ統合ソリューションを構築する必要があることをすぐに理解しました。

Oracle SOA SuiteおよびOracle Coherenceを使用したソリューション

このソリューションは、"顧客のアクティビティの取得"複合アプリケーションを構築するように設計され、次の機能を提供します。

  • 複数のデータソースからのデータを同時に開始および取得する
  • 検索条件に基づいて候補顧客のリストを返す
  • 候補顧客のリストから顧客を選択し、複数のデータソース（Betsy、USDW、およびPubMed）にわたるその候補顧客に固有の集約およ びフィルタリングされた一連のアクティビティ情報を返す
  • ビュー・アクティビティの詳細に対する顧客のアクティビティを選択し、その顧客に固有のアクティビティ情報の詳細を返す
  • エンタイトルメント条件（アクティビティ、チャネル、および地域）に基づいてデータへのユーザーの可視性を制限する
  • 音声的に一致したデータを返す
図3： 統合された顧客情報を表示しているGCA複合アプリケーション


この製薬会社は、プロセスとデータの統合にはOracle SOA Suiteを、また販売担当者に末端情報を配信するためのWeb 2.0レイヤーを提供するためにMicrosoft SharePointを選択しました。

また、SOAデータ・サービスのパフォーマンス向上としてキャッシング戦略を推進することも決定しました。 ただし、このソリューションは、次の3つの重要なキャッシングのニーズを満足できる必要があります。

  • このソリューションは、1つのデバイス上で使用可能なメモリを簡単に超える可能性のあるデータ・サービスのキャッシュ・サイズに対応できる必 要があります。
  • 段階的で、グローバルな採用が予測される場合、このソリューションは、分散キャッシュへのサーバーの追加による線形のスケーラビリティが可能 である必要があります。
  • このソリューションは、会社のSOA中間層にある既存の一連の汎用サーバーを、キャッシングのために考えられるもっとも効率的な方法で活用す る必要があります。

つまり、この会社には、複数の異機種サーバーで使用可能なRAMメモリを、分散した共有メモリ・プールに結合できるソリューションが必要でした。 これらの要件に基づいて、サービス・データを複数の異機種サーバーに分散し、そのデータをクラスタ化されたキャッシュ内のノードで調整するために Oracle Coherenceを選択しました。

図4： Oracle SOA SuiteおよびOracle Coherenceを使用した
"顧客のアクティビティの取得（GCA）"複合アプリケーション


GCA複合アプリケーションは、次のプロセスを通して特定の顧客のアクティビティに関する重要な情報を提供します。

  • Oracle BPEL Process Manager（Oracle BPEL PM）が、ビジネス・サービス（GetCustomer Spain、GetCustomer Germanyなど）をオーケストレーションします。
  • これらのビジネス・サービスが、Oracle Enterprise Service Bus（Oracle ESB）データ・サービス（getActivities、リージョン別のgetCustomers、アプリケーションごとの getCustomeractivity）を起動します。
  • これらのデータ・サービスがさらに、関連するデータソース（Siebel、UNICA、Siperianなど）から（セキュリティおよびガバ ナンス・レイヤーを通して）必要なデータを抽出し、Oracle BPEL PMにデータを戻します。
  • Oracle BPEL PMが最終的に、この結果をSharePointポータル上で販売担当者に表示します。
図5： GetCustomers（Germany）のプロセス・フロー


このデータが販売担当者のPDAに配信される速度は、データ・サービスが基礎となるデータ層からデータを取得できる速度に依存します。 このプロセスでOracle Coherenceが果たす役割を調べてみましょう。

BPEL - Coherenceの統合アーキテクチャ

GCA複合アプリケーション内で、Oracle Coherenceはデータ・サービスの結果データをキャッシュするために使用されます。 このデータは頻繁には変更されないため、Oracle Coherenceはこのデータを、データベース・コール経由でデータソースからではなく、メモリから提供します。

図6： Oracle BPEL PM、Oracle Coherence、およびOracle ESBの間のインタラクション


上の図6は、顧客のアクティビティ情報を抽出するためのOracle BPEL PM、Oracle Coherence、およびOracle ESBの間のシーケンス・フローを示しています。 GetCustomerは、BPELベースのビジネス・サービスです。 このようなビジネス・サービスは通常、（ESBレイヤーにある）GetCustomerActivityデータ・サービスを呼び出し、このデータ・サービ スが次に、基礎となるデータ・サービスから必要なデータを抽出します。

しかし、Coherenceを使用してESBデータ・サービスからの結果データをキャッシングしているため、このシーケンスは少し異なります。 GetCustomerサービスが初めて呼び出されたときは、GetCustomerActivityからの結果がキャッシュされるとともに、 コンシューマに提供されます。 以降の呼出しでは、GetCustomer BPELサービスは最初にキャッシュを参照し、データが使用可能な場合はそこからデータを直接取得します。 中間層のメモリ内へのCustomerActivityデータのキャッシングによって、データのアクセス速度が向上します。

SOAオーケストレーション言語であるBPELから、Coherenceをどれだけ正確に使用する必要があるでしょうか。 この製薬会社の中間層キャッシングの使用目的がスケーラブルなパフォーマンスであったため、アーキテクチャによって効率を下げることはできませんでした。 Oracle CoherenceはJava APIを提供しています。BPELからCoherenceへのネイティブなサービス・コールが、標準のWebサービス・インタフェースより優先されまし た。 Webサービス操作の呼出しのパフォーマンス・オーバーヘッドは、ネイティブなJavaクラスの呼出しのオーバーヘッドより数桁大きくなります。 それは、XMLのマーシャリングとアンマーシャリング、SOAPエンベロープの処理などがコストの高い操作であるためです。

図7： WSIFバインディングを使用した改良されたアプローチ


Javaリソースへのネイティブな接続はBPELの標準機能ではありませんが、Oracle BPEL Process Managerには、この目的のための解決策として、BPELコードの変更や拡張を必要としないWebServices Invocation Framework（WSIF）が用意されています。 Oracle BPEL Process ManagerでのWSIFの使用方法の詳細な説明は、『Oracle BPEL Cookbook』に記載されています。 テストでは、WSIFバインディングを利用することにより、Oracle Coherenceへの標準のWebサービス・インタフェースに比べて桁違いのパフォーマンス向上が得られました。

Oracle BPEL PMとOracle Coherenceの統合

GetCustomer BPELプロセスを簡単に見てみましょう。 下の図8に示すように、このプロセスは最初にキャッシュをチェックします（図10の条件も参照してください）。 キャッシュが空の場合、このプロセスは基礎となるデータ・サービスを呼び出します。そうでない場合は、キャッシュから結果が返されます。

図8： BPEL PMプロセス（GetCustomer）によるCoherenceキャッシュの呼出し


パートナー・リンクでは、さまざまなエンティティ（この場合は、Coherence Webサービス）がBPELプロセスとやり取りする方法が定義されています。 各パートナー・リンクは特定のパートナー・リンク・タイプに関連付けられ、それによって特徴付けられています （図9を参照）。

InvokePagingCacheServiceは、内部的にCoherence WSIF Webサービスを呼び出します。 パートナー・リンク・タイプはWSDLファイルで定義されています。

図9： PagingCacheServiceのパートナー・リンク


下の図10は、PagingCacheServiceから取得されたキャッシュの値に基づいて条件式が定義される方法を示しています。


図10： キャッシュが空かどうかをチェックする条件


これでBPELプロセスがCoherenceキャッシュ・サービスをどのように起動するかが分かったため、次にこのキャッシュ・サービスがどのように作成 されるかを見てみましょう。 簡単に説明すると、このプロセスでは、キャッシュからの読取りやキャッシュへの書込みを行うJavaアプリケーションを作成し、 次にこのJavaアプリケーションを、BPELプロセスから呼び出されるWebサービスとしてラップします。

実装の観点からは、次の手順が必要です。

  1. キャッシュ・サービスのためのリクエストとレスポンスおよびWSDLのスキーマを作成する
  2. スキーマからJavaオブジェクトを作成する
  3. キャッシュ・サービスのためのJava実装クラスを作成する
  4. Coherenceを構成するためのcoherence_config.xmlを作成する
  5. Coherence.jarとTangosol.jarをBPEL Jar内にパッケージ化する
  6. プロセスをデプロイして検証する

1. キャッシュ・サービスのためのリクエストとレスポンスおよびWSDLのスキーマを作成する

BPELプロセスは他のWebサービスと通信するため、複合Webサービスによって起動されるWebサービスのWSDL記述に大きく依存します。

顧客のスキーマに応じて、検索のリクエストとレスポンスのスキーマを準備する必要があります。 たとえば、顧客の検索リクエストには、ファーストネーム、ラストネーム、検索の種類などがあります。 レスポンスには、各顧客の住所や購入した製品などが記載された顧客のリストがあります。

図11： Coherenceキャッシュ・サービスのためのWSDL


2. スキーマからJavaオブジェクトを作成する

スキーマ（SOA Suiteにバンドルされたユーティリティ）を使用して、Javaクラスが作成され、コンパイルされます。

3. Coherenceを呼び出すためのJava実装クラスを作成する

これは、BPEL PMサービスがWSIFインタフェース経由で呼び出すJavaアプリケーションです。 Coherenceキャッシュから読み取り、その結果をBPEL PMサービスに返す必要があるJavaコードの簡単なスナップショットを次に示します。 関連するセクションが黄色でハイライトされています。

public class CacheServiceImpl {
    
     static NamedCache _customerQueryResultCache=null;
     static {

/** Read coherence configuration file to initialize parameters like cache 
    expiration, eviction policy **/

     System.setProperty("tangosol.coherence.cacheconfig", "coherence_config.xml");
                            
       Thread thread = Thread.currentThread();
       ClassLoader loaderPrev = thread.getContextClassLoader();

       try
             {
thread.setContextClassLoader(com.tangosol.net.NamedCache.class.getClassLoader());

/** An instance of a cache is created from the CacheFactory class.  This 
instance, called CustomerQueryResultCache, is created using the getCache() 
method of the CacheFactory class. Cache name GetCustomer.cache is mapped 
to a distributed caching scheme.**/

    _customerQueryResultCache = CacheFactory.getCache("GetCustomer.cache");
    System.out.println("cache: "+_customerQueryResultCache);
          }
      finally
          {
          Thread.currentThread().setContextClassLoader(loaderPrev);
          }
  }

public CacheReadResponseType cacheRead(CacheReadRequestType input) throws 
ApplicationFault, SystemFault, BusinessFault
{
           String key = input.getInput().getKey();
           CacheReadResponseType cacheResponseType = null;
               
/** A CustomerQueryResultCache is a java.util.Map that holds resources 
shared across nodes in a cluster. Use the key (in this case customer id) 
to retrieve the cache entry using the get() method) **/

       CustomerQueryResultSet customerQueryResultSet = 
         (CustomerQueryResultSet)_customerQueryResultCache.get(key);
         System.out.println(" Requested key Id is : " + key);
         System.out.println(" Read from cache is : " + customerQueryResultSet);
         cacheResponseType = CacheReadResponseTypeFactory.createFacade();
         CacheReadResponse cacheResp =
             CacheReadResponseFactory.createFacade();
          if (customerQueryResultSet != null)
          cacheResp.setCustomerQueryResultSet(customerQueryResultSet);
                  
           cacheResponseType.setResult(cacheResp);

          return cacheResponseType;

    }
       
}

4. Coherenceを構成するためのcoherence_config.xmlを作成する

次に、追い出しポリシーやキャッシュの有効期限を含む、キャッシング構成を設定しましょう。 キャッシュ・データが決して期限切れにならないように、有効期限が0に設定された分散キャッシュを使用します。 そうしない場合は、データベース内のデータが変更されるたびにキャッシュを更新することになります。

<distributed-scheme>
   <scheme-name>default-distributed</scheme-name>
   <service-name>DistributedCache</service-name> 
   <backing-map-scheme>
      <local-scheme>
         <scheme-ref>default-eviction</scheme-ref>
    
<!-- Eviction policy set to LRU, so that least recently used cache 
data is evicted to make room for new cache -->
			
        <eviction-policy>LRU</eviction-policy>
        <high-units>0</high-units>
      
<!--Expiry set to 0, so that the cached data never expires. -->
		
       <expiry-delay>0</expiry-delay>
      </local-scheme>
   </backing-map-scheme>
</distributed-scheme>

このcoherence_config.xmlファイルはJarファイル内に置き、プロジェクト・ライブラリに追加する必要があります （図9を参照）。

5. Coherence.jarとTangosol.jarをBPEL Jar内にパッケージ化する

ここでCoherence.jarとTangosol.jarがプロジェクト・ライブラリに追加された後、このプロジェクトが、BPEL- INF/libの下に来るBPEL Jarとともにデプロイされます （図12を参照）。

図12： Coherence jarファイルがBPEL Jarファイルとともにデプロイされる


6. プロセスをデプロイして検証する

このプロセスがデプロイされ、最初の呼出しが行われると、このプロセスはキャッシュ・サーバーを作成し、キャッシュの getCustomer.cacheを作成します。 このキャッシュは、分散キャッシュ・スキーマにマッピングされます。 このキャッシュ・インスタンスから、データの読取りと書込みが行われます。

結論

Oracle Coherenceを使用して中間層キャッシングを実装することにより、複合アプリケーションは、次の大きな利点を得ることができました。

図13： Coherenceキャッシュの読取りが30～50%高速化された
  •  
  • 内部のパフォーマンス・テスト（図13を参照）により、キャッシュからのデータの応答時間が30～50%高速化されることが明らかになりまし た。 また、データがアプリケーション・サーバーに近くなるため、データが簡単に使用でき、データベースとの往復が回避されます。
  • GCA複合アプリケーション内のフォルト・トレランスが向上しました。 どの1台のマシンまたはサーバーに障害が発生した場合でも、データは常に使用可能です。
  • サーバー・ハードウェアの使用率が向上し、サーバー機能をより効率的に使用できます。
  • データ・サービス・コール中のデータのマーシャリング/アンマーシャリングが削減されました。

この記事で示したように、高度な中間層キャッシング・ソリューションを使用することにより、SOAアプリケーションのパフォーマンスを向上させるこ とができます。 適切に設計されたキャッシング製品は、クラスタ化された分散キャッシュの複雑なメカニズムを表に出さずに、SOAアーキテクト/開発者がキャッシュの活用 に集中できるようにします。 これにより、キャッシュの冗長性による信頼性の向上や、シェアード・ナッシング・アーキテクチャからのキャッシュの線形のスケーラビリティなど、さらなる 利点が生まれます。

写真は使用不可 Kiran Dattaniは、大手製薬 会社のアーキテクチャ財務および調達担当ディレクターです。グローバル・アーキテクチャおよびエンタープライズ統合プロジェクトに責任を負っています。 熟練した講演者であり、エンタープライズ統合、およびライフサイエンスや製造業におけるサプライ・チェーンの専門家として認められています。
Milind Pandit Milind Panditは、 Oracle Consulting ServicesのSOAアーキテクトです。SOAベースのアーキテクチャのデプロイメントで顧客を支援しています。 エンタープライズ・アプリケーション統合、J2EE、オブジェクト指向の分析および設計に関連するソフトウェアの設計、開発、および実装で11年の経験を 持っています。
Markus Zirn Markus Zirnは、Oracle Fusion MiddlewareのVice President of Product Managementです。 また、『BPEL Cookbook』の編集者、SOAや関連するトピックに関するいくつかの記事の著者であり、主要な業界およびアナリスト会議で頻繁に講 演を行っています。
false 221529_JA,,,,,,,,,,,,,,,,