 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| BPELを用いたサービス連携 | ||||||||||
|
BPELは、複数のサービスを連携させて、複雑なビジネスフローを定義することができます。人による応答を受け付け、次の処理に移るようなビジネスフローも実現可能です。BPELを実行する環境がBPELエンジンであり、登録したBPELプロセスをWebサービスとして公開することができます。 このシステムでは、業務フローとして、「申請業務」を選択し、「休暇申請」「月報申請」「休日出勤申請」を実現しています。実は、これらの業務フローを完全には定義できていません。 「月報申請」を例にすると、「申請」「承認」「給与計算」「原価計算」という業務フローになります。しかし、現状では「給与計算」や「原価計算」といった機能をサービス化していないため、BPELで実現することはできません。「申請」「承認」という部分的なフローを実現しているという状況です。 確かに全ビジネスフローをBPELで定義し、必要とする機能をすべてサービス化し、理想的なシステムを実現できたらいいのですが、それには多くの費用と期間が必要になります。 そこで、まずは可能なものからBPELで実現し、段階的に拡張する方法を取りました。今後、「給与計算」「原価計算」のサービスが準備できたら、BPELを変更し、サービスと連携させることで、ビジネスフローを拡張することができます。また、このビジネスフローに変更が発生したとしても、柔軟に対応できる可能性を高めることができます。 |
||||||||||
| サービスのメッセージ・スタイル | ||||||||||
|
このシステムでは、サービスへ送信されるメッセージはSOAPメッセージであり、メッセージ・スタイルはDocument/Literalに統一しています。これは、異種プラットフォーム間の相互運用性を向上するための選択です。メッセージスタイルだけ注意すれば、相互運用が実現できるわけでもありません。相互運用性を向上するためには、WS-I（注2）のプロファイルに準拠したWebサービスを構築する必要があります。
※注2：
WS-I
http://www.ws-i.org/ 現状、このシステムでは異種プラットフォーム連携をするようなことはありません。しかし、今後、発展する社内システムのプラットフォームを制限せずに、多くの選択肢を残すことができると考えています。 今回は、勤怠管理システムの特徴とメリットを簡単に紹介しました。後編では、SOAによる構築で見えてきた問題と、弊社システムの将来像と今後の展開を紹介します。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
-
-
連載
