キャメルプルまたはキャメルの統合。 パート1

1つのプロジェクトの歴史。

ラクダを夢見たことはありますか？ だから私もしません。 しかし、3年目キャメルと仕事をするとき、ラクダだけでなく夢を見るようになります。

一般的に、私は私の経験を共有し、ラクダについて書き、それらを調理する方法を教えます。 これは3つのパートに分かれた一連の記事です。最初のパートは、創造性の物語や苦痛に興味がある人向けです。 2番目は、より技術的で、統合パターンとそのアプリケーションについて、3番目は、エラーとデバッグについてです。

サービスを組み合わせる必要がある場合は、ここでCamelの利点を確認できます。 新しいものの使い方を学びたい場合は、基本から始めましょう。 すべてのチームにあるストーリーと元のチップが気に入ったら、読み進めてください。

統合タスク

サービスバスの必要性から始めます。 愛情を込めてモンスターの「目の後ろ」と呼ばれる大規模なシステムを開発しています。 怪物は大きくて恐ろしいことが判明しましたが、実際にはBPMシステム（ビジネスプロセス管理システム）の1つでした。 すべては数年前に始まりました。 会議で、プロジェクトマネージャーは将来の計画について話しました。

-同僚、近い将来、多数の内部および外部システムと統合する予定です。 次に、アナリストがタスクの準備を開始できるように、体系的なアプローチを実行する必要があります。



それからしばらくの間、彼は私たちが統合しなければならないシステムについて話しました。 elibrary.ruなどの外部の有名なシステムと、まだ作成されていない内部のシステムの両方があります。 ストーリーの最後に、さまざまなタイプのシステムとの統合の特徴的な機能が特定されました。 外部システムの場合-これは、交換されるサブジェクトエリアのプロセスとオブジェクト（ビジネスオブジェクト）の記述の大きな不確実性です。 しかし、データ転送の方向（ロードまたはアンロード）は明確でした。 データ伝送チャネルを保護し、配信を保証するための追加要件、および誤ったデータを修正するツールを作成するための前提条件が表示されました。 2番目の内部システムでは、より明確になりました。 各システムの機能的な目的が明確に説明されました。 転送するオブジェクトのサークルを作成することができたおかげで。 しかし、これらのシステムについてのみ、不確実性は私たちがするレベルで現れました-しません、時間があります-それを実現する時間がありません。 アプリケーション領域の詳細に入ることなく、私が集中した典型的なタスクに限定します。

1. 情報は、標準プロトコルを使用してメインシステムにアップロードする必要があります。 議論の時点で、外部システムについてはHTTP、ftp、 内部用：JMS、HTTP、NFS、SMB、および/またはRMIインターフェースを使用。 このアーキテクチャではどのアーキテクチャで解決できますか？
2. メインシステムから情報をアンロードし、標準プロトコルのいずれかを使用して外部システムに転送する必要があるとします。 そのような問題を解決する方法は何でしょうか？
3. または、1つ、2つ、n個のビジネスオブジェクトを転送する必要があります。 どのようにデータを準備し、どの形式を使用するのでしょうか？
4. 一時的に利用できないメールサーバーを介して電子メールメッセージを送信するとします。 これを行うには、ユーザーは後者が利用可能になるまで待つか、現在作業を完了できないことに関するメッセージを受信する必要があります。 配信を保証し、ユーザーをブロックしないシステムをどのように構築できますか？
5. 朝の1時または3時に外部システムから情報を収集する必要があると想定していますが、この時点でシステムはメンテナンスのための作業を中断しました。 メインシステムが使用できないときにデータのアップロードとダウンロードのプロセスが停止しないことを確認する方法
6. 最後のタスク：ログインとパスワードをすばやく変更して、外部システムまたは通信プロトコルにftpからsftpにアクセスできるようにする必要があります。 メインシステムの動作を中断せずに、柔軟に設定を変更できるようにするにはどうすればよいでしょうか？

タスクについて説明した後、メインシステムを他のシステムと接続するスタンドアロンアプリケーションを作成することにしました。 中間リンクを使用するという考え方は新しいものではなく、 エンタープライズサービスバスまたはESBという用語で統合の世界で知られています。 アプリケーションが持つべき機能の範囲を概説しましょう。 タスクの文言に基づきます。 次のことができる必要があります。

• HTTP、FTP、 JMS、またはRMIインターフェースを使用する標準プロトコルを使用して、他のシステムと対話します。
• NFSで作業するために、ローカルファイルシステムでファイルを読み取り、書き込み、作成する
• SMTPサーバーを介してメールメッセージを送信します。
• トランスポートフォーマットXML、JSONのいずれかを解析します
• 柔軟な設定があります
• Javaプログラミング言語の1つであるGroovyでフォーマット承認ルールを記述することができます。 これらの言語で作業したため、学習のための追加のオーバーヘッドがないことを期待できました。
• XSLTとxPathを操作する機能がプラスになります。

推論から実践へ

しばらくして、検索プロセスが勢いを増し始めたとき、アナリストはクライアントに最初のステートメントを書くよう依頼しました。

-みんな、ここでプロダクションを書いたので、すぐにやる必要があります。 顧客は昨日彼女を待っていたので、試してみてください。



これはしばしば起こりますが、私たちは常に新しい機能を時間内に作成することができます。 今回も例外ではなく、大量の作業と実装の厳しい締め切りを待っていました。 この定式化にはサービスバスを使用できませんでしたが、プロトタイプを作成する最初の実用的なタスクとして定式化を使用しました。



それまでの間、プロトタイプを構築するテクノロジーを選択する必要がありました。 自転車を再発明してゼロから始めるのは素晴らしいことですが、費用がかかりすぎます。 結果がすぐに必要だったため、独自のソリューションも使用されませんでしたが、財務上の問題を調整して解決するには時間がかかります。 したがって、彼らはオープンソースプロジェクトに目を向けました。 当時、選択肢は限られていたため、「ラクダ」のメリットを一目で評価することができました。







図からわかるように、Apache Camelは、アプリケーションを統合するためのモジュール式で簡単に拡張可能なフレームワークです。 主な構造要素：コンポーネントモデル、ルーティングメカニズム、メッセージ処理メカニズム。 コンポーネントモデルは、ルーティングエンドポイントを作成するファクトリのセットです。 たとえば、エンドポイントは、ブローカーのJMSキューにメッセージを送信する抽象化である場合があります。 ルーティングメカニズムは、エンドポイントをメッセージ処理の抽象化に関連付けます。 後者のメッセージ処理メカニズムにより、メッセージデータを操作できます。 たとえば、別の形式への変換、検証、新しいコンテンツの追加、ジャーナルなど。 3つのアーキテクチャコンポーネントはすべてモジュール化されており、これにより、Camelの機能は常に拡大しています。 ウィキペディアおよび公式Webサイトで、アーキテクチャの詳細を熟知できます。 登場したばかりのApache Camelは、コンポーネントの堅実なコレクションを取得しました。 JMS、HTTP、ftp、ファイル、SMTP、xPath、xslt、XStream、Groovy、Javaなどのすべての要件を満たすコンポーネントが見つかりました。 Spring Integration、Mule ESB、Apache Camelのどの統合フレームワークを使用すべきかという著者のように？ 、キャメルを選びました。 この記事では、Spring Integration、Mule ESB、およびApache Camelの3つのフレームワークを比較します。 著者は、主な利点を次のように説明しています。

... Apache Camelは、その素晴らしいJava、Groovy、およびScala DSLと、サポートされている多くのテクノロジーが組み合わされているためです。

不器用なXMLの代わりに流fluentなJava DSLを使用できることは、私たちにとって大きな利点になりました。 問題が発生します：不器用なものは何ですか？ XMLは優れたマークアップ言語ですが、JSONまたはYAMLで長い間好まれてきました。 シンプルさ、読みやすさの向上、サポート情報の削減、解析アルゴリズムの簡素化のため、これらが好まれています。 Java、Groovy、Scalaなどのプログラミング言語は、最新のIDEを完全にサポートしています。つまり、XMLとは異なり、デバッグとリファクタリングが可能です。 Camelには疑いの余地がありませんでした。そして、それが私たちのサービスバスの基礎を形成しました。 このプロジェクトが他の企業によって使用されたという事実は、正しい選択に対する信頼を追加しました。

主な疑問は残りました-キャメルをモンスターに統合する方法。

小麦粉：JMS vs RMI。

サービスバスとモンスターの統合は、Camelがサポートする多くのコンポーネントの1つを使用して実装できます。 上記のタスクに基づいて、要件を形成しました。通信は安定し、メッセージ配信を保証する必要があります。 最初の2つは同期RMIとHTTPで、1つは非同期JMSでした。 3つのうち、Javaプロジェクトに適した最も単純な2つのバージョン、JMS、RMIに決めました。 JMS（Javaメッセージサービス）は、メッセージを送信するための標準であり、メッセージの送信、受信、作成、表示のルールを規制します。 2番目のRMI（Remote Method Invocation）は、リモートプロシージャを呼び出すためのプログラミングインターフェイスであり、あるJVMのメソッドを別のJVMのコンテキストで呼び出すことができます。 標準のリモート呼び出し手順には、Javaオブジェクトのパックと受け渡しが含まれます。 公平に言うと、JMSはトランスポートであり、RMIの不可欠な部分になる可能性があるため、JMSとRMIの対比は正しくないことに注意してください。 標準のRMI実装とJMS実装であるActiveMQを比較します。 以前は、RMIを使用して2つのアプリケーションを統合しました。 なぜ彼は選ばれたのですか？ 両方のアプリケーションがJavaである場合、RMIほど簡単なものはありません。 それを使用するには、インターフェースを記述し、このインターフェースを実装するオブジェクトを登録するだけで十分です。 しかし、アプリケーション間で大量のデータを転送するときにRMIで発生する問題を解決する機会がありました。メモリが詰まり、アプリケーションが「スタック」しました。 この問題の解決策を探し、JavaOne JVM開発者と議論しました。 仮想マシンのガベージコレクターと分散コレクターは2つの異なるものであることが判明しました。 それはすべて、標準のガベージコレクターではそのタイプを選択して最適なパラメーターを構成することが可能であるという事実にありますが、分散型ではそのような可能性はありませんでした。 他の違いについて話すと、RMIはJVM上で実行されるアプリケーションへの統合を制限していましたが、JMSはそうではありませんでした。 記載された困難に加えて、RMIを放棄し、代替ソリューションを使用するという新しいことを学びたいという要望がありました。

キャメルの最初のプロトタイプ

プロトタイプの作成に戻りましょう。 サービスバスの最初の実用的なタスクはこれでした。ユーザーがデータをアップロードするプロセスを開始し、システムがそれを準備し、サービスバスに送信します。 すべてのデータ配信作業は彼女にかかっています。 この図は、エンタープライズアプリケーション統合パターン（EIP）のシンボル内の問題ステートメントの例を示しています。



サービスバスは、JMSチャネルからのメッセージの受信、変換、およびHTTP経由の送信を組み合わせます。 図にマークされているJMSチャネルおよびHTMLメッセージ送信チャネルは、Camel JMSおよびJettyコンポーネントを使用して実装されることになっています。 データ変換プロセスは、Javaおよび/またはテンプレートエンジン（VM（Apache Velocity）など）を使用して実装できます。 提案されたデータ転送スキームは、Java DSLで1行で実装されます。 例：

from("jms:queue:se.export") .setHeader(Exchange.HTTP_METHOD,constant(org.apache.camel.component.http.HttpMethods.POST)) .process( new JmsToHttpMessageConvertor() ) .inOnly("jetty:{{externalsystem.uri}}");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の例は、Java DSLルートを示しています。 ルートは、メッセージ送信ルートの説明です。 Camelには、Java DSLとXML DSLの2種類の記述があります。 このようなルートの特性は、開始点と1つ以上の終了点であり、それぞれfromとtokenで示されます。 ルートは、開始点から終了点までのメッセージパスを記述します。 エンドポイントが順番に示されている場合、メッセージは最初のエンドポイントに送信され、サービスバスは応答を待ってから、次のポイントに送信します。 目的のエンドポイントを選択するルート（ Dynamic Router ）、または複数のポイントにメッセージを一度に送信するルート（ Recipient List ）が存在する場合があります。 fromおよびtokensパラメーターは、URIを含む文字列です。 URIは、Camelコンポーネントの名前、リソース識別子、および接続パラメーターで構成される3つのパラメーターです。 例を見てみましょう：

 from(“jms:queue:se.export?timeToLife=10000”)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、JMSコンポーネントを使用するエントリポイントの説明です。 JMSコンポーネントは、キューからデータを取得する機能を提供します：se.exportリソース。 キューはメッセージチャネルのタイプであり、キューまたはトピックのいずれかです。 次に、チャネル名「se.export」が来ます。 この名前のキューは、メッセージブローカーによって作成されます。 URIの最後の部分であるエンドポイントパラメータ「timeToLife = 10000」は、パケットのライフタイムが10秒であることを示します。

この例から、データの転送をどのように編成するかが明確になりました。次の記事では、より実際のコードと例があります。

そこで、データ転送の問題を解決し、Camelで構成され、実装の準備がほぼ整った統合バスのプロトタイプを作成しました。 正しく便利な構成の問題を解決するために残った。

プロトタイプのセットアップ

実際のアドバイスや実装例を見つけるのは難しいため、このトピックには非常に感銘を受けました。

スタンドの構造は次のとおりです。

各開発者はソフトウェアの独自のコピーを所有しており、それを起動する前に完全に構​​成します。 手動テスト用に2つのテストベンチがあり、もちろん動作するシステムがあります。 問題の説明は次のとおりです。

• 各スタンドの微調整は、システム構成ファイル内のパラメーターの最小数を編集するだけで行う必要がありました。
• すべてのスタンドで大規模なカスタマイズ（新機能の追加）がシームレスに実行されました

また、開発者のスタンドでプロジェクトビルダー（Maven）を使用することはできましたが、テストスタンドと運用サーバーでは使用できませんでした。

このタスクには多くの困難があります。CamelはJMSブローカーと接続されているため、異なるスタンドまたは異なるメッセージブローカーに異なるチャネルを使用する必要があります。 バスに統合されたActiveMQブローカーを起動することにより、最も簡単な方法を実行しました。 この場合、異なるサーバーに接続設定を提供することは残ります。



キャメル設定でパラメーターを使用する例に移りましょう。

1. camel-config.xmlの例
   
   

    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <list> <value>classpath:system.properties</value> <value>classpath:smtp.properties</value> </list> </property> </bean>
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   この例では、Springの2つの構成ファイルを設定します。
2. 前の例の2つのファイルで指定された設定を使用する例。
   
   

    <bean id="someServiceStartPolicy" class="org.apache.camel.routepolicy.quartz.CronScheduledRoutePolicy"> <property name="routeStartTime" value="${config.someService.routeStartTime}"/> <property name="routeStopTime" value="${config.someService.routeStopTime}"/> </bean>
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   プロパティ自体は、「$ {config.someService.routeStartTime}」行で設定されます
   
   
3. 複数の設定ファイルがCamelコンテキストに転送される例
   
   

    <camelContext id="rootCamelRoute" xmlns="http://camel.apache.org/schema/spring"> <propertyPlaceholder id="properties" location="smtp.properties, system.properties"/> … </propertyPlaceholder> </camelContext>
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
4. Java DSLのCamelルートでパラメーターを使用する例
   
   

    from("jms:queue:email.send") .setHeader("to", simple("${headers.email}")) .setHeader("from", simple("${properties:config.smtp.from}")) .to("{{config.smtps.server}}?username={{config.smtps.user}}&password={{config.smtps.password}}&contentType=text/html&consumer.delay=60000")
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   ここでは、パラメータをアドレス指定するいくつかの方法が一度に使用されます。 ここにあります：
   
   -単純な方言では、文字列「$ {properties：config.smtp.to}」
   
   -文字列「{{config.smtps.server}}」を持つエンドポイントURI
   
   パラメーター名は任意です。行は上記の例から取られています。
   
   

本当の問題を想像してみましょう。

サービスバスを介してSMTPサーバーにレターを送信するサービスがあります。 このようなサービスは、稼働中のシステムのユーザーにメッセージを送信し、テストシステムの場合、すべてのレターを1つのメールボックスに送信する必要があります。

次に、このタスクは、テストシステムと実稼働システムで実行されるいくつかのルートに異なるロジックを追加するように変換されます。



キャメルルートのパラメーターを使用して、このような問題を解決する方法の例を次に示します。

 from("jms:queue:event.recoverypass") .setHeader("to", isDebug() ? simple("${properties:config.smtp.to}") : simple("${headers.email}")) .setHeader("from", simple("${properties:config.smtp.from}")) … // some other headers .choice() .when( header("password").isNotNull() ) .setHeader("subject", simple("${properties:config.passwordNotify}")) .to("velocity:vm/email/newPasswordNotify.vm") .otherwise() .setHeader("subject", simple("${properties:config.recoverypass}")) .to("velocity:vm/email/recoveryPassword.vm") .end() .to("{{config.smtps.server}}?username={{config.smtps.user}}&password={{config.smtps.password}}&contentType=text/html&consumer.delay=60000")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のサンプルコードは、パスワード回復サービスに必要です。 次のロジックが実装されます：ユーザーがパスワードのリセットボタンをクリックし、新しいパスワードを生成するための一時リンクを含む電子メールがユーザーに送信され、ユーザーがリンクをクリックし、同じルートがユーザーに新しいパスワードをメールで送信します。 それはおそらく最初の部分が完了するべき場所であり、それは在庫を取るためだけに残っています。

まとめ

バスのプロトタイプが完成しました。メッセージを送信するためのいくつかのルートが登場し、バスの構成と展開を容易にする構成ファイルが登場しました。 キャメルをマスターする最初のステップの結果によれば、そのようなアプローチの大きな可能性について話すことができます。 ルート作成のシンプルさと簡潔さが魅力的です。 すべてを1行で実行できるようです。 ただし、ルートの操作には考え方の変更が必要であるという事実に注意する必要があります。 それらに対処しなかったプログラマーにとっては、すぐに「エンタープライズアプリケーションの統合テンプレート」という本に目を向けることが最善です。 統合パターンを理解することの効果は、従来のOOPで設計パターンを知ることの効果に匹敵します。



さようなら、さようなら。 次のパートでお会いしましょう。 キャメルのユースケースに専念することを思い出させてください。