Exposing Serviced Components by Using Web Services

In the .NET Remoting samples in Chapter 4, we exposed a .NET component and through Component Services, consuming it in Java with Intrinsyc's Ja.NET. We can now do the same with Web services. To expose the serviced components via Web services, however, we'll create an additional layer to enable them to be called from a suitable client.

Can't You Just Use SOAP Activation?

SOAP activation in Component Services for Microsoft Windows Server 2003 can be used to expose a Serviced Component to either .NET or Java. SOAP activation is the option in which a SOAP endpoint is automatically generated and hosted through Microsoft Internet Information Services (IIS) for deployed components.

Given that this SOAP endpoint could be accessed by using HTTP via a WSDL document that's created for you, it begs the question of whether the endpoint could be classified as a Web service (and whether you could just use the sample client created in the previous section in order to consume it). Unfortunately, the answer is "not always."

Although SOAP, HTTP, and WSDL were used to construct the endpoint, the WSDL generated by using the SOAP activation option is not XML Schema Definition (XSD) compliant. In essence, the WSDL that's generated by using SOAP activation contains data types that are specific to .NET Remoting (and not based on XSD). As a result, the types exposed have the potential to be consumed by using either a .NET client or a Java client that understands .NET Remoting (for example, with Ja.NET installed). But in most cases, a Web services implementation that doesn't understand the .NET Remoting data types cannot access the service. To overcome this, you'll now see how to publish the components in the same way as before, and how a small layer can be used to accept incoming Web service requests and pass them on to the hosted components.

Publishing the Serviced Components

The samples that you'll reuse are located in the C:\Interoperability\Samples\Point\WebServices\dotNETComponentServices\Server directory. These samples expose the same methods used in the .NET Remoting example in Chapter 4, but they don't publish a SOAP VRoot (the SOAP endpoint). In addition, the name of the component is changed slightly to allow the .NET Remoting and Web service components to run side by side.

As before, the sample code shows an implementation of the GetRecommendations and BuyStocks methods that are hosted by Component Services. To build and deploy the server component, run the NAnt script in the Server directory by using the invoke target. This will build the StockServer DLL file, create an Invoker subdirectory, and install the component. Running NAnt on its own will build the component but not install it. This can be useful for deploying to other machines. For additional information on building the server component, refer to the "Java Client to .NET Object, Hosted by Component Services" section in Chapter 4.

Note

In certain rare cases, you might get a System.Runtime.InteropServices.COMException exception when the invoke.bat file is executed (which implicitly occurs when the invoke target is used with the provided NAnt script). As was the case in Chapter 4, the StockServerWS component will be deployed, but it needs to be configured to run under a different identity in order to run properly. Open the Properties window for the StockServerWS component within Component Services, and select the Identity tab. Select This User, enter account credentials for a valid user account, and click OK. Now rerun the NAnt script with the invoke target to complete the StockServerWS component installation.

The layer that allows these components to be exposed by using Web services can be found in the C:\Interoperability\Samples\Point\WebServices\dotNETComponentServices\WebService directory. To configure the Web services layer, build the sample code and create a virtual root in IIS that points to this directory. (This was shown in the scripted .NET Web service at the start of Chapter 5.) To run the Web services sample side by side with the .NET Remoting sample, use the alias StockServerWS. (The .NET Remoting sample used StockServer.)

Once the virtual directory has been created, browse to http://localhost/StockServerWS/StockService.asmx?WSDL . This will show the WSDL document for the Web service.

How Does the Web Service Wrapper Work?

Essentially, the Web service wrapper is simply a class that's hosted through Microsoft ASP.NET as a Web service and that exposes the same methods as the original component.

Looking at the main Web service class, StockService.asmx.cs, you can see how the Web service exposes these methods. First, two instances of the SampleData and StockServerWS classes are created when the Web service is invoked:

 private SampleData _servicedComponentSampleData      = new SampleData(); private StockServerWS _servicedComponentBuyStocks      = new StockServerWS();

After this, the methods from each of the classes are exposed as a Web method:

 [WebMethod] public ArrayList getRecommendations() {     return _servicedComponentSampleData.getRecommendations(); } [WebMethod] public bool BuyStocks(Stock stock, int quantity) {     return _servicedComponentBuyStocks.BuyStocks(stock, quantity); }

As this code demonstrates , although Component Services do not facilitate exposing components as Basic Profile “compliant Web services, it's easy to generate a wrapper that can expose components this way.

Consuming the Exposed Component

You consume the serviced component via this Web service in the same way as shown in the earlier basic samples, including the sample that consumed the EJB via Web services. Two clients (one for .NET and one for Java) located in the dotNETClient and JavaClient subdirectories of C:\Interoperability\Samples\Point\WebServices\dotNETComponentServices will demonstrate this.

Build and run the clients to test consuming the Serviced Component using Web services. To prove that the component is being invoked and managed by Component Services, you can use the Component Services administration tool to observe the life cycle of the component.

To do this, launch the Component Services administration tool from Start Menu/Programs/Administrative Tools/Component Services. Navigate through the Component Services hierarchy in order to open a folder named Running Processes, as shown in Figure 6.2. Before you execute the client, this folder will contain no existing processes (with the exception of some systems and any other applications that you've installed). Run either of the clients and observe how the StockServerWS component is invoked. The figure shows how the component exposed by the Web service layer is listed under the running processes.

Figure 6.2: Using the Component Services administration tool.