自称週末ファーマーの国家試験受験記

自己啓発の延長なのか、自己実現の手段なのか、はたまた意地の張り合いか。生きているうちに“何か”を成し遂げたいから走り続けているような感じがする

第121話 経営情報システム⑰ SEさんの得意なところなの?

今回のテーマは『システム構成技術』だそうです。これまではコンピュータの内部などについてみてきたが、今回からシステム形態や性能、信頼性の評価などコンピュータシステム全体を概観します。

1.情報システムの構成技術
1)処理形態
 情報システムの処理形態は、「いつ処理をするのか」という軸で分類すると、バッチ処理とリアルタイム処理とに分類される。
複数の処理をまとめて一括処理するのがバッチ処理。ユーザの要求ごとに都度処理するのがリアルタイム処理。
バッチ処理
 一定期間(もしくは一定量)データを集め、一括処理する方法。1日に1回なら日次処理だし、週に1回なら週次処理だし、月に1回なら月次処理となる。月間の売上集計や給与計算などは月単位で集計するから月次処理となる。

 バッチ処理 → まとめて処理

リアルタイム処理
 処理をためずにユーザからの要求の都度すぐに処理を行う方式。リアルタイム処理に向くのは、座席予約やATM、荷物追跡といった業務。処理が中断されるとデータの整合性が取れなくなるのでトランザクション管理が重要なポイントになってくる。
なお、リアルタイム処理のうち、トランザクション単位で各端末からの要求を順次処理する方式を、OLAPとよぶ。

 ●リアルタイム処理 → 都度処理
 ●OLAP → リアルタイム処理の一種

 次は「どこで処理するか」という軸で考えれば、処理を1ヵ所で行うのが集中処理。複数箇所で行えば分散処理と分類される。
集中処理
 CSS(クライアントサーバシステム)が登場するまで、処理を実行するコンピュータはホストコンピュータと呼ばれていた。ホストコンピュータは各端末からの情報が集約され、そこで処理がなされる。そうすると、ホストコンピュータが故障した際はすべての処理が停止することになる。
分散処理
 ネットワーク接続された複数のコンピュータで処理を分散して実行する方式
分散処理の代表的なシステムを、CSS(クライアントサーバシステム)という
CSSは、サービスを要求し提供を受けるクライアント側と、サービスを提供するサーバ側で役割を分散させるものだ。

 CSS → 分散処理の代表的なシステム。
        役割を分散するのでレスポンスタイムは低下する

 このCSSは役割を分散させるので1機器に対する負荷は少なくなるが、いかんせん分散して処理をさせているので、集中処理システムに比べてレスポンスタイムが低下する。

 CSS(クライアントサーバシステム)をもう少し細かく見ていこう。
CSSは分散処理の1形態であり、CSSを構成するにもいくつかに分類できる。
①2層アーキテクチュア
 CSSで連携処理するアプリケーションを3つの機能モジュールに分割して、1つのアプリケーションを2層構造で連携処理していくシステム。
ここでいう「3つの機能」とは、プレゼンテーション層、ファンクション層、データベース層であり、これらを2つに分離する。2つの層への分け方には特に決まりはないらしいが、基本的には、サーバ側にデータベース層を、クライアント側にプレゼンテーション層とファンクション層をおく。

 ●2層アーキテクチュア → 3機能を2層構造で連携処理

 2層アーキテクチュアには次のような問題点がある。一つ目に、クライアントの処理能力に大きく依存するということ。クライアント側にアプリケーションの実行やデータの加工、表示を任せるので利用が高度になれば高性能なPCが必要になる。二つ目には、サーバと各クライアントは密接に結びついているのでサーバ側で何か変更や修正があった場合にクライアント全てに対して同様な変更や修正を施す必要が出てくることだ。これが大きな負担。

 ●2層アーキテクチュア → クライアント側に負担。fatクライアント

②3層アーキテクチュア
 そこで登場したのが3層アーキテクチュア。3機能を分割して3層構造で連携処理をさせるというもの。プレゼンテーション層、ファンクション層、データベース層の3つの層に機能を明確に分離することでシステム性能や開発容易性を向上させている。
・プレゼンテーション層 → ユーザインタフェースを提供する
・ファンクション層 → データの処理や加工を行う
・データベース層 → DBへのアクセスを行う
 クライアントはプレゼンテーション層のみを担当するので負担が少ない。だから比較的低性能のPCでも対応は可能。負担が少ないという意味でthinクライアント。

 ●3層アーキテクチュア → 3機能を独立させる。thinクライアント

 それぞれの層で独立性が高いので層間での依存性が少ない。各機能が独立しているので保守・運用もラクになる。3層アーキテクチュアはどの層にどの機能を持たせるかといった論理的な概念であり、どの層をクライアント、サーバのどちらに持たせるかといった物理的な構成を規定したものではない

2.Webサービス
 Webサービスは、Webサーバ間でWebアプリケーションを連携したものWebサービスではXML形式の文書を使って相互にアプリケーションを呼び出したり、データを送受信する。このXML文書のやりとりに必要な規約をSOAPという(後述)。

 Webサービス → Webサーバ間を、XML形式でやりとり

 例えば、Web上で旅行予約をしようとした場合、チケット手配、宿泊手配、時刻表、観光地情報など各種サービスを個々に利用して1つずつ検討する必要があった。Webサービス上では、例えば、宿泊予約をしただけで、チケット手配や時刻表、観光地情報などが一括して手続されるようなイメージがWebサービスだ。

SOAP
 Simple Object Sccess Protocol の略。Webサービスの連携に必要なXMLドキュメントを交換するためのルール
Webサービスは、顧客の利便を図るために、各サーバ同士がXML形式の文書によって交換される必要がある。このときのルールを定めたものがSOAPということになる。HTTPなどのインターネット上の標準プロトコルを使用するため、ファイアウォールなどを通過でき、複数のネットワーク間での利用が可能になる

 SOAP → Webサービスに使うXML文書をやりとりする規約

UDDI
 Universal Description Discovery and Integration の略。Webサービスを登録・検索するための仕組み(アドレス帳みたいなもの)。このアドレス帳には、インターネット上のどこに、どんなビジネスが、どんな形式で行われているかが格納されている。Webサービスを公開している企業は、UDDIに登録するだけで宣伝などをしなくても顧客にサービス内容を伝えることが出来る。
 なお、UDDIは、Webサービスの情報を管理するDBをもつ。これをUDDIレジストリという。UDDIレジストリでは、Webサービスの情報をXMLによって登録管理する。

 ●UDDI → Webサービスの登録、検索
 ●UDDIレジストリ → Webサービスの情報を管理するデータベース

WSDL
 Web Service Description Language の略。XMLによりWebサービスを利用するためのインタフェースを記述するための仕様Webサービスを使用したい場合、UDDIに問い合わせて、必要なWSDLを取得する必要がある。つまり、Webサービスを利用するために必要な手続書みたいなイメージであって、WSDLを持っていないとWebサービスを提供する企業にアクセス出来ない

 WSDL → Webサービスを使用するためにUDDIより取得


3.SOA
 SOAとは、Service Oriented Architecture の略で、システムの単位をサービスという概念で捉え構築する設計手法開発効率を重視して、XMLベースの部品を柔軟に組み合わせて構築する。XML形式標準プロトコルでメッセージ送受信を行うインターネット技術を組み合わせて、アプリケーションサービスを提供する技術。サービス指向アーキテクチュア。

だんだん専門的になってきましたね。
まだこのへんはついていけるけれど、徐々に弱気になっていく自分がいたのは事実。

ふ~。

続く。