- PR -

Webサービスのデザインについて

1
投稿者投稿内容
OZ
常連さん
会議室デビュー日: 2006/02/27
投稿数: 45
投稿日時: 2006-03-01 20:23
現在Webサービスの作成を行っているのですが、Webシステム・Javaの経験が浅いため、
設計のところで悩んでいます。

悩んでいる点は、ビジネスロジックを機能毎にメソッド化するのですが、そのメソッドの
集合を大きな一つのクラスにするか、メソッド毎にクラス化しEJBとするかです。

もちろんケースバイケースだと思いますが、どういったケースの時はどの点を考慮しなくては
ならないというノウハウが無いので、Webサービス・EJBを作成する上で気を付けた方が
良い点や、犯しがちな失敗等ございましたらご教授して頂けるでしょうか。

よろしくお願い致します。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2006-03-02 06:05
クラスの単位はインターフェースとなる EJB を一つ作って一通りメソッドを押し込んでしまってはいかがでしょうか。
あまりに数が多くて困るという場合に初めてクラスを分ければ良いかと。

また、Webサービスの性質により考えることは様々ありそうですが、一般的な話としてはメソッドの粒度を粗めにするということが大切です。
細かいビジネスロジックを組み合わせた Facade EJB を作り、そのメソッドを公開すれば何度にもわたってメソッドコールを行わなくて済みますのでトランザクションについてセンシティブに考えなくて済みますし、パフォーマンス上も有利です。

Webサービスを利用する立場となって、内部のデータベースの構成などを意識しなくても簡単に呼び出しが行えることを意識してできる限りシンプルかつ汎用的(内部実装が変更になってもメソッド定義に影響が及ばない)なインターフェースにしましょう。
OZ
常連さん
会議室デビュー日: 2006/02/27
投稿数: 45
投稿日時: 2006-03-02 16:39
インギさん、アドバイスありがとうございます。

私の理解が間違っていないかチェックして頂けるとありがたいです。

引用:

クラスの単位はインターフェースとなる EJB を一つ作って一通りメソッドを押し込んでしまってはいかがでしょうか。
あまりに数が多くて困るという場合に初めてクラスを分ければ良いかと。

これは、

public class Webサービスクラス｛
　public 公開メソッド１
　public 公開メソッド２
　public 公開メソッド３
　・・・

　private 共通処理１
　private 共通処理２
　・・・
　private 内部処理１
　private 内部処理２
　・・・
｝

という構造にし、公開メソッドの数が増えすぎるようであれば、別クラスとする。

引用:

また、Webサービスの性質により考えることは様々ありそうですが、一般的な話としてはメソッドの粒度を粗めにするということが大切です。

これは、インターフェースとなる公開メソッドは、機能毎に細分化したメソッドを準備し
シンプルな本質的処理だけを行うようにする。
前処理やデータ等の加工はprivateな外出しの処理とする。

という感じであっているでしょうか？

引用:

細かいビジネスロジックを組み合わせた Facade EJB を作り、そのメソッドを公開すれば何度にもわたってメソッドコールを行わなくて済みますのでトランザクションについてセンシティブに考えなくて済みますし、パフォーマンス上も有利です。

このご説明のイメージが湧きませんでした。
これは、上記のWebサービスクラスを直接公開するのではなく、公開メソッドを組み合わせた
形のメソッドをインターフェースとするラップクラスを作成するという事でしょうか。

よろしくお願い致します。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2006-03-02 17:06
大体私の認識は伝わっていると思います。
私のイメージではこんな感じでしょうか。
コード:
public interface Webサービスインターフェース{
  public 公開メソッド1();
  public 公開メソッド2();
}

public class Webサービスクラス implements Webサービスインターフェース{
  public 公開メソッド1(){
    内部処理クラス ns = new 内部処理クラス();
    ns.内部処理1();
    ns.内部処理2();
    return ns.内部処理3();
  }
  public 公開メソッド2{
    new 内部処理クラス().内部処理4();
  }
}


/*package*/ class 内部処理クラス{
  /*package*/ 内部処理1();
  /*package*/ 内部処理2();
  /*package*/ 内部処理3();
  /*package*/ 内部処理4();
}

OZさんの要件を元に具体的に設計したわけではないので実体にそぐわない可能性も大いにあります。
参考程度に・・・。
>これは、上記のWebサービスクラスを直接公開するのではなく、公開メソッドを組み合わせた
>形のメソッドをインターフェースとするラップクラスを作成するという事でしょうか。
そうですそうです。説明が下手でごめんなさい。

まぁ、設計なんて宗教みたいなもので絶対というものはありません。
人によってしっくりくるものが、他の人にとってはありえない設計だったりします。

Webサービスを作る上で大切なのはインターフェースの恒久性です。内部の実装が変わっても公開されているメソッドの引数や返り値に変更がないようできるだけ一般化するのが良いでしょう。

内部実装はテストケースさえしっかり作ってあればリファクタリングしながらいくらでもごちゃごちゃ書き直せます。気楽に行きましょう♪
#まぁ、実際の開発は思い通りフレキシブルにはいかないものですが
OZ
常連さん
会議室デビュー日: 2006/02/27
投稿数: 45
投稿日時: 2006-03-02 17:32
>>これは、上記のWebサービスクラスを直接公開するのではなく、公開メソッドを組み合わせた
>>形のメソッドをインターフェースとするラップクラスを作成するという事でしょうか。
>そうですそうです。説明が下手でごめんなさい。

とんでもありません！私の方こそ理解不足で恐縮です。

ここまで丁寧に説明して頂けると、Java・Webの経験の浅い私には非常に助かります。

>Webサービスを作る上で大切なのはインターフェースの恒久性です。内部の実装が変わっても公開されているメソッドの引数や返り値に変更がないようできるだけ一般化するのが良いでしょう。

この部分に注意しながら設計してみたいと思います。

あと不安なのが、Webでサービスを公開するので複数セッションからの同時アクセスを
考慮しなければならないのですが、構造的に考慮する点とかはあるでしょうか？
また、初心者(素人)がやりがちなミス等ありましたら、ポイントを挙げて頂けると助かります。

重ね重ね申し訳ございません。よろしくお願い致します。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2006-03-02 17:38
「複数セッション」というのはマルチスレッドでメソッドが呼びだされるということでしょうか？
Webサービスのフレームワークによっては Web サービス内からいわゆる HttpSession にアクセスする手段を用意しているものがありますが、Webサービスでは通常使いませんので。

マルチスレッドに起因するバグとなると、Webサービスに限ったことではないですが変数のスコープを意識することが重要ですね。
例えば JDBC コネクションを１つだけ取得して全部のスレッドで使い回したらパフォーマンスがひどいことになったりトランザクションもへったくれもなくなったりします。
どうしても共有すべき値についてはしっかり synchronized メソッドなりブロックなりを使ってマルチスレッド動作による値の不整合を防ぐ必要があります。
サーブレットのコーディング、ラッシュテストなどをすればここらへんの感覚はつかめてくると思います。
OZ
常連さん
会議室デビュー日: 2006/02/27
投稿数: 45
投稿日時: 2006-03-02 18:04
引用:

マルチスレッドに起因するバグとなると、Webサービスに限ったことではないですが変数のスコープを意識することが重要ですね。
例えば JDBC コネクションを１つだけ取得して全部のスレッドで使い回したらパフォーマンスがひどいことになったりトランザクションもへったくれもなくなったりします。
どうしても共有すべき値についてはしっかり synchronized メソッドなりブロックなりを使ってマルチスレッド動作による値の不整合を防ぐ必要があります。
サーブレットのコーディング、ラッシュテストなどをすればここらへんの感覚はつかめてくると思います。

インギさん、丁寧なご説明ありがとうございます。
教えて頂いた事に注意して開発してみます。
また何かありましたら、お願い致します。
1

スキルアップ／キャリアアップ（JOB@IT）