概要
コンポーネント・ベースのプログラミングは、かつてないほど普及している。今日、何らかの形でコンポーネントを利用しないアプリケーションはほとんどない。アプリケーションがより高度になるにつれて、リモート・マシンに分散されたコンポーネントを活用する必要性も高まっている。.
コンポーネントベースのアプリケーションの例として、エンドツーエンドのeコマースソリューションがあります。Webファーム上に存在するeコマースアプリケーションは、バックエンドのエンタープライズリソースプランニング（ERP）アプリケーションに注文を送信する必要があります。多くの場合、ERPアプリケーションは異なるハードウェア上に存在し、異なるオペレーティングシステム上で実行されます。.
マイクロソフトの分散コンポーネント・オブジェクト・モデル（DCOM）は、 アプリケーションが別のサーバーにインストールされたコンポーネント・オブジェクト・モデル（COM）コンポーネントを呼び出すことを可能にする分散オブジェクト・インフラストラクチャであり、Windows以外のプラットフォームにも数多く移植されている。しかし、DCOMはこれらのプラットフォームで広く受け入れられることはなかったため、WindowsとWindows以外のコンピュータ間の通信を促進するために使用されることはほとんどない。ERPソフトウェアベンダーは、Windowsプラットフォーム用に、独自のプロトコルを介してバックエンドシステムと通信するコンポーネントを作成することが多い。.
eコマース・アプリケーションが利用するサービスの中には、データセンター内にまったく存在しないものもある。例えば、eコマース・アプリケーションが、顧客が購入した商品のクレジット・カード決済を受け付ける場合、顧客のクレジット・カード情報を処理するために、マーチャント・バンクのサービスを引き出す必要がある。しかし、DCOMや、CORBAやJava RMIなどの関連技術は、実用上、企業のデータセンター内にインストールされたアプリケーションやコンポーネントに限定される。その2つの主な理由は、デフォルトでこれらの技術はプロプライエタリなプロトコルを活用し、これらのプロトコルは本質的に接続指向であることである。.
インターネットを介してサーバーと通信するクライアントは、サーバーと通信する際に多くの潜在的な障壁に直面する。世界中のセキュリティ意識の高いネットワーク管理者は、インターネットを介したあらゆる種類の通信を実質的に許可しないように、企業のルーターやファイアウォールを導入している。ネットワーク管理者が最低限以上のポートを開放するためには、しばしば不可抗力が必要となる。.
運良くネットワーク管理者がサービスをサポートするために適切なポートを開いてくれたとしても、クライアントはそれほど幸運ではないかもしれない。その結果、DCOM、CORBA、Java RMIで使用されているようなプロプライエタリなプロトコルは、インターネットのシナリオでは実用的ではない。.
もうひとつの問題は、申し上げたように、これらのテクノロジーは本質的に接続指向であるため、ネットワークの中断を優雅に扱うことができないということだ。インターネットはあなたの直接のコントロール下にないため、接続の品質や信頼性についていかなる仮定もすることができない。ネットワークが中断すると、クライアントが次にサーバーにかける電話は失敗するかもしれない。.
また、これらの技術の接続指向の性質は、高いスケーラビリティを達成するために必要な負荷分散されたインフラを構築することを困難にしている。クライアントとサーバー間の接続が切断されると、次のリクエストを単純に別のサーバーにルーティングすることはできない。.
と呼ばれるモデルを活用することで、開発者はこれらの制限を克服しようとしてきた。 ステートレス プログラミング, しかし、この技術はかなり重く、遠隔地との接続を再構築するにはコストがかかるため、その成功は限られている。.
顧客のクレジットカードの処理はインターネット上のリモート・サーバーによって行われるため、DCOMはeコマース・クライアントとクレジットカード処理サーバー間の通信を促進するのに適していない。ERPソリューションと同様に、サードパーティのコンポーネントがクライアントのデータセンター内にインストールされることが多い（この場合、クレジットカード処理ソリューション・プロバイダーによって）。このコンポーネントは、Eコマース・ソフトウェアとマーチャント・バンク間の通信を独自のプロトコルで促進するプロキシに過ぎない。.
ここにパターンがあるだろうか？コンピューター・システム間の通信を容易にする既存のテクノロジーには限界があるため、ソフトウェア・ベンダーはしばしば独自のインフラ構築に頼ってきた。つまり、ERPシステムやクレジットカード処理システムの機能向上に使えたはずのリソースが、独自のネットワーク・プロトコルの作成に費やされているのだ。.
このようなインターネット・シナリオをよりよくサポートするために、マイクロソフトは当初、クライアントとリモート・コンポーネントの間にポート80を介したDCOM接続を確立できるCOMインターネット・サービス（CIS）など、既存の技術を補強する戦略を採用した。さまざまな理由から、CISは広く受け入れられることはなかった。.
新しいアプローチが必要であることは明らかだった。そこでマイクロソフトは、ボトムアップでこの問題に取り組むことにした。このソリューションが成功するために満たすべき要件をいくつか見てみよう。.
- 相互運用性 リモート・サービスは、他のプラットフォームのクライアントが利用できなければならない。.
- インターネットへの対応 このソリューションは、インターネットからリモート・サービスにアクセスするクライアントをサポートするのにうまく機能するはずである。.
- 強い型付きインターフェイス リモートサービスとの間で送受信されるデータの型については、あいまいであってはならない。さらに、リモートサービスによって定義されたデータ型は、ほとんどの手続き型プログラミング言語によって定義されたデータ型にうまく対応しなければならない。.
- 既存のインターネット標準を活用する能力 リモートサービスの実装は、できる限り既存のインターネット標準を活用し、すでに解決済みの問題に対する解決策の再発明を避けるべきである。広く採用されているインターネット標準に基づいて構築されたソリューションは、その技術のために作成された既存のツールセットや製品を活用することができる。.
- あらゆる言語に対応 ソリューションは、特定のプログラミング言語と緊密に結合すべきではない。たとえばJava RMIは、Java言語と緊密に結合している。Visual BasicやPerlからリモートJavaオブジェクトの機能を呼び出すのは難しいだろう。クライアントは、そのクライアントが書かれたプログラミング言語に関係なく、新しいWebサービスを実装したり、既存のWebサービスを利用したりできるべきである。.
- あらゆる分散コンポーネント・インフラをサポート ソリューションは、特定のコンポーネント・インフラと緊密に結合すべきではない。実際、新しいリモートサービスを構築したり、既存のサービスを利用したりするためだけに、分散オブジェクト基盤を購入、インストール、維持する必要はないはずだ。基礎となるプロトコルは、DCOMやCORBAのような既存の分散オブジェクト基盤間の基本レベルの通信を容易にするものでなければならない。.
本書のタイトルを考えれば、マイクロソフトが開発したソリューションが次のようなものであることは驚くにはあたらないだろう。 ウェブサービス. .Webサービスは、クライアントに代わって特定のアクティビティを呼び出すためのインターフェイスを公開します。クライアントは、インターネット標準を使用してWebサービスにアクセスすることができます。.
Webサービス・ビルディング・ブロック
次の図は、2つのアプリケーション間のリモート通信を容易にするために必要な、中核となるビルディング・ブロックを示している。.
これらの各構成ブロックの目的について説明しよう。多くの読者はDCOMに精通しているので、各構成ブロックのDCOMに相当するものについても言及する。.
- ディスカバリー ウェブサービスによって公開された機能へのアクセスを必要とするクライアントアプリケーションは、リモートサービスの場所を解決する方法を必要とする。これは、一般的に ディスカバリー. .ディスカバリは、集中型ディレクトリを使用する方法と、よりアドホックな方法で行う方法がある。DCOMでは、サービスコントロールマネージャ（SCM）がディスカバリサービスを提供する。.
- 説明 特定のWebサービスのエンドポイントが解決されると、クライアントはそのWebサービスと適切に対話するために十分な情報を必要とする。Webサービスの記述は、クライアントアプリケーションによって消費されるインターフェイスに関する構造化されたメタデータと、使用例を含むWebサービスに関する文書化された文書を含んでいる。DCOM コンポーネントは、型ライブラリ（typelib）を介して、そのインターフェイスに関する構造化されたメタデータを公開する。コンポーネントの typelib 内のメタデータは、独自のバイナリ形式で保存され、独自のアプリケーションプログラミングインタフェース（API）を介してアクセスされる。.
- メッセージ形式 データを交換するためには、クライアントとサーバーはメッセージをエンコードしフォーマットする共通の方法に合意しなければならない。データをエンコードする標準的な方法は、クライアントによってエンコードされたデータがサーバーによって適切に解釈されることを保証する。DCOMでは、クライアントとサーバーの間で送信されるメッセージは、DCOM Object RPC（ORPC）プロトコルで定義されたとおりにフォーマットされる。.
メッセージをフォーマットする標準的な方法がなければ、開発者を基礎となるプロトコルから抽象化するツールセットを開発することは不可能に近い。開発者と基礎となるプロトコルの間に抽象化レイヤーを作成することで、開発者は目の前のビジネス問題に集中することができ、ソリューションの実装に必要なインフラに集中する必要がなくなる。.
- エンコーディング クライアントとサーバー間で送信されるデータは、メッセージ本体にエンコードされる必要がある。DCOMは、クライアントとサーバーの間で交換されるパラメーターに含まれるデータをシリアライズするために、バイナリーエンコーディングスキームを使用します。.
- 輸送 メッセージがフォーマットされ、データがメッセージ本体にシリアライズされると、メッセージは何らかのトランスポートプロトコルを介してクライアントとサーバー間で転送されなければならない。DCOMは、TCP、SPX、NetBEUI、NetBIOS over IPXなど、多くのネットワークプロトコルにバインドされた多くの独自プロトコルをサポートしている。.
ウェブサービス設計の決定
これらのウェブ・サービスの構成要素の背後にある設計上の決定について説明しよう。.
Choosing Transport Protocols
The first step was to determine how the client and the server would communicate with each other. The client and the server can reside on the same LAN, but the client might potentially communicate with the server over the Internet. Therefore, the transport protocol must be equally suited to LAN environments and the Internet.
As I mentioned earlier, technologies such as DCOM, CORBA, and Java RMI are ill suited for supporting communication between the client and the server over the Internet. Protocols such as Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP) are proven Internet protocols. HTTP defines a request/response messaging pattern for submitting a request and getting an associated response. SMTP defines a routable messaging protocol for asynchronous communication. Let’s examine why HTTP and SMTP are well suited for the Internet.
HTTP-based Web applications are inherently stateless. They do not rely on a continuous connection between the client and the server. This makes HTTP an ideal protocol for high-availability configurations such as firewalls. If the server that handled the client’s original request becomes unavailable, subsequent requests can be automatically routed to another server without the client knowing or caring.
Almost all companies have an infrastructure in place that supports SMTP. SMTP is well suited for asynchronous communication. If service is disrupted, the e-mail infrastructure automatically handles retries. Unlike with HTTP, you can pass SMTP messages to a local mail server that will attempt to deliver the mail message on your behalf.
The other significant advantage of both HTTP and SMTP is their pervasiveness. Employees have come to rely on both e-mail and their Web browsers, and network administrators have a high comfort level supporting these services. Technologies such as network address translation (NAT) and proxy servers provide a way to access the Internet via HTTP from within otherwise isolated corporate LANs. Administrators will often expose an SMTP server that resides inside the firewall. Messages posted to this server will then be routed to their final destination via the Internet.
In the case of credit card processing software, an immediate response is needed from the merchant bank to determine whether the order should be submitted to the ERP system. HTTP, with its request/response message pattern, is well suited to this task.
Most ERP software packages are not capable of handling large volumes of orders that can potentially be driven from the e-commerce application. In addition, it is not imperative that the orders be submitted to the ERP system in real time. Therefore, SMTP can be leveraged to queue orders so that they can be processed serially by the ERP system.
If the ERP system supports distributed transactions, another option is to leverage Microsoft Message Queue Server (MSMQ). As long as the e-commerce application and the ERP system reside within the same LAN, connectivity via non-Internet protocols is less of an issue. The advantage MSMQ has over SMTP is that messages can be placed and removed from the queue within the scope of a transaction. If an attempt to process a message that was pulled off the queue fails, the message will automatically be placed back in the queue when the transaction aborts.
Choosing an Encoding Scheme
HTTP and SMTP provide a means of sending data between the client and the server. However, neither specifies how the data within the body of the message should be encoded. Microsoft needed a standard, platform-neutral way to encode data exchanged between the client and the server.
Because the goal was to leverage Internet-based protocols, Extensible Markup Language (XML) was the natural choice. XML offers many advantages, including cross-platform support, a common type system, and support for industry -standard character sets.
Binary encoding schemes such as those used by DCOM, CORBA, and Java RMI must address compatibility issues between different hardware platforms. For example, different hardware platforms have different internal binary representation of multi-byte numbers. Intel platforms order the bytes of a multi-byte number using the little endian convention; many RISC processors order the bytes of a multi-byte number using the big endian convention.
XML avoids binary encoding issues because it uses a text-based encoding scheme that leverages standard character sets. Also, some transport protocols, such as SMTP, can contain only text-based messages.
Binary methods of encoding, such as those used by DCOM and CORBA, are cumbersome and require a supporting infrastructure to abstract the developer from the details. XML is much lighter weight and easier to handle because it can be created and consumed using standard text-parsing techniques.
In addition, a variety of XML parsers are available to further simplify the creation and consumption of XML documents on practically every modern platform. XML is lightweight and has excellent tool support, so XML encoding allows incredible reach because practically any client on any platform can communicate with your Web service.
Choosing a Formatting Convention
It is often necessary to include additional metadata with the body of the message. For example, you might want to include information about the type of services that a Web service needs to provide in order to fulfill your request, such as enlisting in a transaction or routing information. XML provides no mechanism for differentiating the body of the message from its associated data.
Transport protocols such as HTTP provide an extensible mechanism for header data, but some data associated with the message might not be specific to the transport protocol. For example, the client might send a message that needs to be routed to multiple destinations, potentially over different transport protocols. If the routing information were placed into an HTTP header, it would have to be translated before being sent to the next intermediary over another transport protocol, such as SMTP. Because the routing information is specific to the message and not the transport protocol, it should be a part of the message.
Simple Object Access Protocol (SOAP) provides a protocol-agnostic means of associating header information with the body of the message. Every SOAP message must define an envelope. The envelope has a body that contains the payload of the message and a header that can contain metadata associated with the message.
SOAP imposes no restrictions on how the message body can be formatted. This is a potential concern because without a consistent way of encoding the data, it is difficult to develop a toolset that abstracts you from the underlying protocols. You might have to spend a fair amount of time getting up to speed on the Web service’s interface instead of solving the business problem at hand.
What was needed was a standard way of formatting a remote procedure call (RPC) message and encoding its list of parameters. This is exactly what Section 7 of the SOAP specification provides. It describes a standard naming convention and encoding style for procedure-oriented messages.
Because SOAP provides a standard format for serializing data into an XML message, platforms such as ASP.NET and Remoting can abstract away the details for you.
Choosing Description Mechanisms
SOAP provides a standard way of formatting messages exchanged between the Web service and the client. However, the client needs additional information in order to properly serialize the request and interpret the response. XML Schema provides a means of creating schemas that can be used to describe the contents of a message.
XML Schema provides a core set of built-in datatypes that can be used to describe the contents of a message. You can also create your own datatypes. For example, the merchant bank can create a complex datatype to describe the content and structure of the body of a message used to submit a credit card payment request.
A schema contains a set of datatype and element definitions. A Web service uses the schema not only to communicate the type of data that is expected to be within a message but also to validate incoming and outgoing messages.
A schema alone does not provide enough information to effectively describe a Web service, however. The schema does not describe the message patterns between the client and the server. For example, a client needs to know whether to expect a response when an order is posted to the ERP system. A client also needs to know over what transport protocol the Web service expects to receive requests. Finally, the client needs to know the address where the Web service can be reached.
This information is provided by a Web Services Description Language (WSDL) document. WSDL is an XML document that fully describes a particular Web service. Tools such as ASP.NET WSDL.exe and Remoting SOAPSUDS.exe can consume WSDL and automatically build proxies for the developer.
As with any component used to build software, a Web service should also be accompanied by written documentation for developers who program against the Web service. The documentation should describe what the Web service does, the interfaces it exposes, and some examples of how to use it. Good documentation is especially important if the Web service is exposed to clients over the Internet.
Choosing Discovery Mechanisms
Once you’ve developed and documented a Web service, how can potential clients locate it? If the Web service is designed to be consumed by a member of your development team, your approach can be pretty informal, such as sharing the URL of the WSDL document with your peer a couple of cubicles down. But when potential clients are on the Internet, advertising your Web service effectively is an entirely different story.
What’s needed is a common way to advertise Web services. Universal Description, Discovery, and Integration (UDDI) provides just such a mechanism. UDDI is an industry-standard centralized directory service that can be used to advertise and locate Web services. UDDI allows users to search for Web services using a host of search criteria, including company name, category, and type of Web service.
Web services can also be advertised via DISCO, a proprietary XML document format defined by Microsoft that allows Web sites to advertise the services they expose. DISCO defines a simple protocol for facilitating a hyperlink style for locating resources. The primary consumer of DISCO is Microsoft Visual Studio.NET. A developer can target a particular Web server and navigate through the various Web services exposed by the server.
What’s Missing from Web Services?
You might have noticed that some key items found within a distributed component infrastructure are not defined by Web services. Two of the more noticeable omissions are a well-defined API for creating and consuming Web services and a set of component services, such as support for distributed transactions. Let’s discuss each of these missing pieces.
- Web service -specific API Most distributed component infrastructures define an API to perform such tasks as initializing the runtime, creating an instance of a component, and reflecting the metadata used to describe the component. Because most high-level programming languages provide some degree of interoperability with C, the API is usually exposed as a flat set of C method signatures. RMI goes so far as to tightly couple its API with a single high-level language, Java.
In an effort to ensure that Web services are programming language-agnostic, Microsoft has left it up to individual software vendors to bind support for Web services to a particular platform. I will discuss two Web service implementations for the.NET platform, ASP.NET and Remoting, later in the book.
- Component services The Web services platform does not provide many of the services commonly found in distributed component infrastructures, such as remote object lifetime management, object pooling, and support for distributed transactions. These services are left up to the distributed component infrastructure to implement.
Some services, such as support for distributed transactions, can be introduced later as the technology matures. Others, such as object pooling and possibly object lifetime management, can be considered an implementation detail of the platform. For example, Remoting defines extensions to provide support for object lifetime management, and Microsoft Component Services provides support for object pooling.
Summary
Component-based programming has proven to be a boon to developer productivity, but some services cannot be encapsulated by a component that resides within the client’s datacenter. Legacy technologies such as DCOM, CORBA, and Java RMI are ill-suited to allowing clients to access services over the Internet, so Microsoft found it necessary to start from the bottom and build an industry-standard way of accessing remote services.
ウェブサービス is an umbrella term that describes a collection of industry- standard protocols and services used to facilitate a base-line level of interoperability between applications. The industry support that Web services has received is unprecedented. Never before have so many leading technology companies stepped up to support a standard that facilitates interoperability between applications, regardless of the platform on which they are run.
One of the contributing factors to the success of Web services is that they’re built on existing Internet standards such as XML and HTTP. As a result, any system capable of parsing text and communicating via a standard Internet transport protocol can communicate with a Web service. Companies can also leverage the investment they have already made in these technologies.