なぜ、基幹システムをWebシステムで？
»
ちょっと、疲れてきたのでユルめに。
昔、イントラネット、エクストラネットなんて言葉がありました。今はほとんど聞かなくなりましたが……。
余談ですが、SaaSなんてASPと変わらないし、エクストラネットと言ってたときも、﹁WEBページだからこそ、サービスを組み合わせることができる﹂とか、クラウドに近いことを言ってたし。その後に、やたらマッシュアップ！ マッシュアップ！ と言うようになって、クラウドとか新しい言葉を作らないとマーケティング上やりにくいってことかな。
わたしはそういう言葉先行が大嫌いで……だから儲からないのでしょうね。
それはさておき、今更ですが、ざっくりと比較してみると。
| リッチクライアント | WEBシステム | |
| パフォーマンス | ★★★★★ | ★☆☆☆☆ |
| 操作性（入力時） | ★★★★★ | ★☆☆☆☆ |
| 操作性（参照時） | ★★★★★ | ★★★★☆ |
| 工数 | ★★★★★ | ★★☆☆☆ |
| インストール | ★★★☆☆ | ★★★★★ |
| 保守性 | ★★★★★ | ★★★★★ |
| マルチOS | ★☆☆☆☆ | ★★★☆☆ |
| 外部公開 | ★★★☆☆ | ★★★★★ |
| シンクライアント | ☆☆☆☆☆ | ★★★☆☆ |
Webシステムは、マルチOSや外部公開、シンクライアント対応しなければ意味がないのです。ところが﹁OSはWindows XP以上、とかブラウザはIE7以上、それ以外は保証しません﹂とかね……。これを書いちゃうということは、もう意味がわかってないのです。
そもそもWebシステムは、Webブラウザ︵閲覧ソフト︶で基幹システムの入力機能を作ってしまうのはかなり問題があります。
本来的には、Webシステムはダム端末と同じです。クライアントでの処理は表示とユーザーからのリクエストを受け付けること、ダム端末との違いは、マウス操作がベースになっていてサブ画面が簡単に開くこと、あくまで本来はね。
ブラウザは閲覧ソフトですから、参照系には非常に便利にできています。しかし、データ入力にはそもそも向いていないので、凝ったことをしようとすると無理やりスクリプトなどを埋め込む必要があり、大変な工数が掛かったり、パフォーマンスが落ちてしまったりします。
結果、シンクライアントやマルチブラウザなどでは実現できなくなったりします。メリットはインストールの手間だけになったりしますが、それなら、リッチクライアントでインストールプログラムや再配布のプログラムをしっかり作った方が良いわけです。
基幹システムでも、外部公開をすることもありますが、すべてを公開することはできません。ブラウザ用と携帯用など、それぞれに合わせて作ることも多いでしょう。
であるなら、内部用と公開用と二重に作った方がよい。そのときには、SQL︵ストアドプロシージャ︶にロジックを入れている方が再利用しやすい。いつもの方向ですな︵笑︶。
もちろん、パッケージのようにRDBMSが変わるということもあるでしょうが、基幹システムなどではRDBMSが変わるより、他が変わる方が圧倒的に多い。
SQLの使い方から、WEBシステムにするかどうかまで、とにかく決め打ちはいけない。必ず、それぞれの意味を考えて方針を決めなければなりません。
コメント
にゃん太郎
生島さん、おはようございます。
Webシステムは確かに便利なんだけど、何でもWebシステムって言うのは違和感が
ありますよね。前にあった要件でお客様がWebシステムでお願いしますと言うから
話を聞いてみると検索・表示よりも追加・変更・更新の方が多いシステムでした。
しかも、通常はバッチでやりそうな処理もオンラインでやりたいんだとか。流行っ
てコワイわ。
それにしても、最終的にいつものSQLに話が行くところはさすがです︵笑︶
kim
生島さん。
今回も共感するテーマですので、投稿させて頂きました。
︵1︶﹁基幹システムはＷＥＢシステムでやりたくない﹂について。
いろいろ案件やってきましたが、下記の操作性は必須要件でした。
・ファンクションキーの利用。
・ＥＮＴＥＲキーでのフォーカス移動。
﹁InputMan﹂とか﹁X-WebForm﹂などがプロパティ設定で
上記操作要件をＷＥＢシステムでもクリアできるとのことですので、
ＷＥＢシステムは進化しているのは確かだと思います。
ＷＥＢの入力操作性については、今後の動向を注目していきたいと思います。
︵2︶ストプロで﹁業務ロジックを入れる﹂について 卸売業ですと、小数点の端数処理や消費税計算処理は得意先別に異なります。 ですから得意先マスタにその区分を持つのが普通です。 ストプロでそれらの処理を実装しておけば、 例えば売上伝票入力画面でフォーカス遷移時にそのストプロをコールすれば、 瞬時に画面に計算結果を表示してくれます。 また売上ＣＳＶデータ一括入力があれば、同じストプロを利用できます。 ＷＥＢシステムだといちいちポストバックしなくてはいけません。 ︵ＡＪＡＸ技術を使えば可能なのかもしれませんが。。。︶ クソ忙しい現場で、﹁何でちょっとの処理でポストバックかかるの？﹂ とユーザさんのストレスは増大するばかりです。 上記︵1︶、︵2︶より やはり﹁基幹システムは、Ｃ／Ｓでやりましょう﹂が私の結論です。
︵2︶ストプロで﹁業務ロジックを入れる﹂について 卸売業ですと、小数点の端数処理や消費税計算処理は得意先別に異なります。 ですから得意先マスタにその区分を持つのが普通です。 ストプロでそれらの処理を実装しておけば、 例えば売上伝票入力画面でフォーカス遷移時にそのストプロをコールすれば、 瞬時に画面に計算結果を表示してくれます。 また売上ＣＳＶデータ一括入力があれば、同じストプロを利用できます。 ＷＥＢシステムだといちいちポストバックしなくてはいけません。 ︵ＡＪＡＸ技術を使えば可能なのかもしれませんが。。。︶ クソ忙しい現場で、﹁何でちょっとの処理でポストバックかかるの？﹂ とユーザさんのストレスは増大するばかりです。 上記︵1︶、︵2︶より やはり﹁基幹システムは、Ｃ／Ｓでやりましょう﹂が私の結論です。
にゃん太郎さん、どうも。
通常、バッチ処理をオンラインは目指すべきところじゃないですかね。
私が始めたころのマシンと比べると、マシンはリアカーとF1ぐらいの差になっていると思うので、どんどんオンラインで処理できる範囲が広がってくるのが発展だと思います。
オンラインにしても、入力締めは業務上作らないといけないのですけれど、中小企業はいつでも直せるようにして欲しいと言われますな。赤黒を極端に嫌うからな～。
結果、いくらでも不正ができるシステムになってしまうけど、会社として性善説に基づいているからOKなのでしょう。しかし、いまだにJSOXが関連するような規模の企業でも言われて固まることもある。
苦労するのは技術だけじゃないね。
kimさん、どうも。
決め打ちせず、流行りもちゃんと吟味してたら、同じような考えになりますよね。
﹁ストプロ﹂というのもいい感じです。
私は話するときに相手に合わせますけれど﹁ストアド﹂って言ってる人は意味がわかってないんじゃないかと、かなり不安になります。︵でも、私も言うけどね︶
英語圏の人が聞いたら、﹁彼らは﹃保存された﹄﹃保存された﹄って言ってるけど何の話をしているのか？﹂ってなりますよね︵笑︶
oumi
>SQL︵ストアドプロシージャ︶にロジックを入れている方が再利用しやすい
中途半端にせずに、この際﹁業務ロジックは、RDBMSがWEB Serviceで公開してしまうのが再利用しやすい﹂って言っちゃいましょうよ！？。
saki1208
saki1208です。
DB以外の所で業務ロジックを実装するとバッチ処理の内部ロジックに同じ物を再
実装しないといけないケースが出てきますよねぇ。
マスタのチェックとか…
# 入力時は当然チェックされてるけど、その後削除なんて場合ですが…
で、結局あちこちに処理が散りばめられるので保守性も低下してしまう。
# webの場合だと尚更該当箇所を探すのに苦労するし。
設計次第な部分もあるのでしょうけど。
にゃん太郎
生島さん、こんにちは
> 通常、バッチ処理をオンラインは目指すべきところじゃないですかね。
個人的にはバッチで問題ないならバッチ処理でいいじゃん、と思ってます。
ケースバイケースと言うよりもTPOかな。確かにマシンのスペックは驚くほど
上がっているけど、そこを目指すところかどうかは今現在はそうじゃない気も
します︵将来はわかりませんが︶
ただ、この時は1台のマシン︵サーバーOS︶にWebサーバー、APサーバー、
DBをすべて載せてやれって言われたからリアルタイムでなくても問題ない物は
極力バッチ処理にしてました。
saki1208さん、どうも。
ビジネスロジックのうちデータが関連する部分はDB側で処理するのが効率的ですし、ユーザの判断が介在したり、ユーザの動作が介在する処理はUI側にあるべきでしょう。
当たり前のことしか言ってない気がするのですけれど、オブジェクト指向派の人たちは、ストアドにロジックを入れたらロジックが分散すると言うのですけどね。
何を基準に分散すると言ってるのか全然わからない。
ケースバイケースではあって、ここでコメントをくれているような人は実は分かってると思う。問題は黙っている人とか、はてブで明後日のコメントを書いている人とかかな。
梅田望夫さんの気持ちがよく分かる︵苦笑︶
WEBの話に戻すと、相当な工数を掛けて作った入力システムも結局使いにくいと一蹴されて、エクセルで作ったデータをアップロードしてたり︵笑︶
WEBシステムで外部公開していても、ネットワークが内向きに開いているならエントリー系はC/Sで作った方が絶対にコストは安くつくし、ユーザビリティも高い。
営業上C/Sからのリプレイスの言い訳のためとか、流行っているからとか、なんと言うか、分からなくはないのですけれど……。
oumi
>オブジェクト指向派の人たちは、ストアドにロジックを入れたらロジックが分散すると言うのですけどね
理想論としては、オブジェクトが生成されたときに、必要なデータがさくっとロードされて、オブジェクトが消滅する時に、自動的にセーブされるのが望ましいわけですから、そのあたりを意識してなんじゃないですかね。
もしくは、「なんか４層的になっちまう！？」みたいなこと？かも（W)
そもそも、二次元のデータストアに「オブジェクト(の構造) + 内部データ => 二次元データ」に変換してストアしなきゃだめなわけですから、ストプロどころかRDBMSに保存ってのが、いまいちなんですけどね。
色々な概念のハイブリッドでやってるんだってことを忘れちゃってるんですよきっと・・
インドリ
>当たり前のことしか言ってない気がするのですけれど、オブジェクト指向派の人たちは、ストアドにロジックを入れたらロジックが分散すると言うのですけどね。
そんな事言うのですか・・・これは酷い。
データベースエンジニアリングを学んでいませんね。
データベースを学んでいる人はこんな事いいません。
オブジェクト指向派？なんて関係なくタダの勉強不足だと思います。
インドリ
私が言っているのは生島さんが言及している自称オブジェクト指向派の人の事です。
多分これなんちゃってオブジェクト指向です。
本格派の人はデータ中心アプローチも併用します。
これは、オブジェクト指向プログラミングで構造化プログラミング対応の機能を使うの同じですよね。
oumi
見逃してたので。
>C/Sも視野に入れてるので、WebServiceはちょっと……。
>セキュリティ面でコストが増大するでしょうし。
C/S 環境下で、RDBMS が用意しているSOAP 1.1 のサービス︵XML WEB Service︶を使うという意味で言ったので、ネットに公開って事じゃないのです。
グローバルじゃないってだけですからセキュリティを言いだせばそれなりにありますけど、基本的には普通のDBコネクションとなんら変わらないと思う。
なんていうかロールベースでセキュリティかけましょう的な部分ね。
やったことはないのですけど、確かSQL Server がストアドをWEB Serviceを公開できるとか・・・他RDBMSにもそんな機能があるなら、結構一般化できそうな気もしますが。
将来無くなる機能だったかも。。。
これなら、可能性あるのじゃないですか？︵無くなる機能かもしれないけど・・︶
結構面白そうなんですけどね。スケールもかなりよさそうですし。
oumiさん、どうも
弊社が設計したわけではないのですけれど、SOAPはちょうど今やっていてXMLって無駄に転送量が大きくなって……。問題がないわけではないですね。
近い将来、少々の転送量は関係ない時代になるかもしれませんが、なくなるかもしれないし、微妙な感じです。
今やっているのになんですが、積極的には手を出したくないな……。
C/Sシステムからのマイグレーションで下記のようなシステムが開発されています。
http://www.adobe.com/jp/aboutadobe/pressroom/pressreleases/200905/20090513_rtgs_ria.html
C/SからRIAにする大きな理由がクライアントソフトの配布が不要との事ですが如何思われますでしょうか。
インドリ
Webサービスについては価値があると思います。
Webサービスはその名の通り﹁サービスを提供﹂ビジネスと考えればよいかと思います。
ですから、自社がシステム構築するのに、一々Webサービスで構成する必要は余りありません。
しかし、自社の技術を売るとなればWebサービスを提供するのもありだと思います。
それとSOAPは、XMLである事が冗長となりますが、XMLは同じパターンである事が多いので有効な圧縮法が存在します。
木村祥久さん、どうも。
本文の
> 結果、シンクライアントやマルチブラウザなどでは実現できなくなったりします。
> メリットはインストールの手間だけになったりしますが、それなら、リッチ
> クライアントでインストールプログラムや再配布のプログラムをしっかり作った
> 方が良いわけです。
の部分のとおりです。
C/Sで可能な環境ならインストーラをダブルクリックするだけとか、サイレントインストールとかの手段がありますが、それらを作りこんでも1～数人日ほどで出来ると思います。
その数人日を他のものでトレードオフするのはおかしいと言ってるわけです。
oumiさん、インドリさん、どうも。
SOAPを使うなら、いろんなシステムで再利用できないと意味がないのですけれど、個人的な経験では、XMLの冗長性のためタグをケチって再利用できないことが多い。
というか﹁SOAPを使ってみました﹂みたいな案件が多いかな。
WEBサービスは、あくまでWEBサービスなので、ここでは別の話ですね。
oumi
>SOAPを使うなら、いろんなシステムで再利用できないと意味がないのですけれど
私も、WS-*をウォッチしはじめた頃は、そう思ってたんですけど、少したったら、そうではなくて、分散処理の1方法であるとだけ思うようになりました。
サブシステム間連携、レガシー接続、スループットのあまり要求されない処理の追い出しの方法の1つ、場合によっては異種ＯＳ連携、そんな感じですね。
格好良く言えばSOAってなるのかもしれませんけど。ま、サービスＢＵＳを扱うミドルもいろいろとあるわけですから、なかなかいいですよ。
oumiさん、どうも。
分散処理のひとつなのですけれど、関連する全部のDBでSOAPを導入するのは、かなりハードルが高いと思う。 個人的にはそういう当たり前の使い方をしているプロジェクトの経験がないので、流行る前に消えるのかなと思って、積極的に手が出せない。 私は保守的なので、ウォッチはしてもある程度流行るまで手を出すことはないし、SOAPって流行る前に消えたと言えるレベルかも……。
分散処理のひとつなのですけれど、関連する全部のDBでSOAPを導入するのは、かなりハードルが高いと思う。 個人的にはそういう当たり前の使い方をしているプロジェクトの経験がないので、流行る前に消えるのかなと思って、積極的に手が出せない。 私は保守的なので、ウォッチはしてもある程度流行るまで手を出すことはないし、SOAPって流行る前に消えたと言えるレベルかも……。
放牧民
こんにちは。
共有するロジックをストアドにまとめるのは私もよくやります。
というか、私は共有するor重い処理だけストアドってケースが多いんですが、
そういうケースに限って多い
・DBにストアせずにファイルシステムとして保存するデータが存在する
・トランザクションの最中に外部との通信が必要
のような、﹁データ﹂がDB単体で閉じないケースはちょっと悩んじゃいます。
解決できないわけではありませんが、もどかしく感じることが多いんですよね。
ちなみに、 >WEBの話に戻すと、相当な工数を掛けて作った入力システムも結局使いにくい >と一蹴されて、エクセルで作ったデータをアップロードしてたり︵笑︶ 何故か、お客さんがWebで作ることを主張してくるケースも多いですよね。 で、結局こういうオチになるという... まあ時効だと思いますのでちょっと余談を失礼します。 昔、某大手ニュース系サイトの入稿UIをWebで作ることを強要されました。 しかも無意味に複雑系かつ無茶な要求で、2,3ヶ月くらいは軽くかかりそうな勢い。 提案した本人以外の誰の目から見ても、何らメリットが見えないような代物。 ただ幸いにも、とある新コーナー専用だったこと、実験的なコーナーだったことを鑑みて、 ﹁まずはExcelの入力シートからアップしましょう。 で、アクセス数や更新負荷を睨んでから改めて考えましょう。 その代わり、アップの仕組みは直ぐに作りますから。﹂ となんとか説得。 そして、提案をしたその日にマクロ込みでリリースをしました。 Excelなので入力生産性も高く、オフラインでも利用可能(記者には重要)というわけで思惑通り好評頂き、この流れをうまくコントロールできれば、と思っていたのですが・・・ 3ヶ月後、コーナー自体消滅してましたｗ いや、ｗなんてつけちゃダメなんですが、なんというかｗが正直な気持ちでした。
ちなみに、 >WEBの話に戻すと、相当な工数を掛けて作った入力システムも結局使いにくい >と一蹴されて、エクセルで作ったデータをアップロードしてたり︵笑︶ 何故か、お客さんがWebで作ることを主張してくるケースも多いですよね。 で、結局こういうオチになるという... まあ時効だと思いますのでちょっと余談を失礼します。 昔、某大手ニュース系サイトの入稿UIをWebで作ることを強要されました。 しかも無意味に複雑系かつ無茶な要求で、2,3ヶ月くらいは軽くかかりそうな勢い。 提案した本人以外の誰の目から見ても、何らメリットが見えないような代物。 ただ幸いにも、とある新コーナー専用だったこと、実験的なコーナーだったことを鑑みて、 ﹁まずはExcelの入力シートからアップしましょう。 で、アクセス数や更新負荷を睨んでから改めて考えましょう。 その代わり、アップの仕組みは直ぐに作りますから。﹂ となんとか説得。 そして、提案をしたその日にマクロ込みでリリースをしました。 Excelなので入力生産性も高く、オフラインでも利用可能(記者には重要)というわけで思惑通り好評頂き、この流れをうまくコントロールできれば、と思っていたのですが・・・ 3ヶ月後、コーナー自体消滅してましたｗ いや、ｗなんてつけちゃダメなんですが、なんというかｗが正直な気持ちでした。
放牧民さん、どうも。
お客さんがWebで指定してくるのは本当によくわからないけれど、リストラの一環で入力業務を行う人が居なくなってきて、従来なら資料を見て判断するだけの人が、自分の担当分は入力するようになってきているから。
というのであれば、ある程度正しい方向と思います。
それでも、入力機能は別に作った方がよい場合が多いのですけどね…。
> ・DBにストアせずにファイルシステムとして保存するデータが存在する
> ・トランザクションの最中に外部との通信が必要
ストアドプロシージャについては……、どっちがいいのでしょうね。
外付けのDLLやEXEや外部ファイルを叩いたり、リンクDBを使うこともありますね。
こうなってくると、どっちもどっち、って答えになるのですけれど︵笑︶
個人的な経験では、同じお客様、同じ環境で、ストアドプロシージャから外部ファイル＆リンクDBのパターン︵弊社が作った︶と似たことを母言語でグルグルしているパターン︵他社が作った︶の経験がありますけど100～1000倍前後の差になったな。他社は弊社の機能のために用意していた予算まで食いつぶして、担当者はノイローゼになってたけど、他社だけに助けられなかった。
助けてほしいと言ってくれたら助けられたのに…。でも、人月400万も取って私が参加した当時は私など虫ケラのように見てたからね。
頭が下げれなかっただろうし、そんな他社の連中に手助けはね…。
コメントを投稿する
SpecialPR