ice.NET Service Builder

The ice.NET Service Builder is a tool to generate the service interface implementation (interoperability layer, adapter) out of a service configuration as described in Service Configuration. The Service Builder can generate interfaces for various connection technologies:

  • ASP.NET Web Service implementation
  • ASP.NET Web Service client
  • Rich Client Service Interface (direct database access)
  • Abstract client interface implemented by Web Service and Rich Client

The following diagram illustrates how the Service Builder works:

As a prerequisite for running the Service Builder, the business logic must be compiled into modules (assemblies, Business Logic DLLs). The Service Builder consumes a configuration file (.iceservice Format) that references these DLLs and contains a list of method categories and a list of products to be produced. For each of the products the Service Builder generates one or more source code files that can be included into appropriate development projects. Compiling the generated source code is not part of the Service Builder process.

A typical service configuration file looks like this: 

<?xml version="1.0" encoding="ISO-8859-1"?>
<ServiceBuilder>
    <Service Name="Walkthrough" DisplayName="Walkthrough Service">
        <Assembly FileName="ServiceWalkthrough.BusinessLogic\bin\Debug\ServiceWalkthrough.BusinessLogic.dll" />
        <Category Name="Walkthrough" />
    </Service>
    <Debug AnalysisFileName="analysis.xml" />
    <CodeGeneration>
        <Logging Enabled="true" LoggerName="test.sb"/> 
        <Product Type="Interface" TargetDirectory="ServiceWalkthrough.Service.Interface">
            <Param Name="Namespace" Value="ServiceWalkthrough.Service.Interface" />
        </Product>
        <Product Type="WebService" TargetDirectory="ServiceWalkthrough.Service.Web.Service">
            <Param Name="SoapNamespace" Value="http://tempuri.org/" />
            <Param Name="Namespace" Value="ServiceWalkthrough.Service.Web.Service" />
        </Product>
        <Product Type="DatabaseClient" TargetDirectory="ServiceWalkthrough.Service.DatabaseClient">
            <Param Name="InterfaceNamespace" Value="ServiceWalkthrough.Service.Interface" />
            <Param Name="Namespace" Value="ServiceWalkthrough.Service.DatabaseClient" />
         </Product>
        <Product Type="WebServiceClient" TargetDirectory="ServiceWalkthrough.Service.WebServiceClient">
            <Param Name="InterfaceNamespace" Value="ServiceWalkthrough.Service.Interface" />
            <Param Name="Namespace" Value="ServiceWalkthrough.Service.WebServiceClient" />
            <Param Name="WebServiceProxyClass" Value="ServiceWalkthrough.Service.WebServiceClient.WalkthroughWebReference.WalkthroughServiceWebService" />
            <Param Name="LoggingFramework" Value="log4net" />
       </Product>
    </CodeGeneration>
</ServiceBuilder>

In the Service element the modules (assemblies) and categories are listed that define the method and parameter structure of the resulting service. In the optional Debug element an output file can be specified that contains the result of the analysis of the modules in a readable XML format. The CodeGeneration elemnent contains all products (= sets of generated source code files). The Type attribute specifies the kind of interoperability/adapter code to be generated.

The following diagram illustrates how the products are related to each other:

The Business Logic module(s) is/are the basis for the configured/generated service. The (abstract) service client interface is generated from the Business Logic and does not technically depend on any other module. Therefor, a user interface (Application GUI) or an integration component can be implemented on top of this interface, independent from the specific service connection technology.

If a Rich Client application is to be developed, the generated DatabaseClient component is sufficient to implent the adapter layer between the service interface and the service implementation. The DatabaseClient implements the interfaces generated in the Service.Interface module and directly references the Business Logic module. This provides a complete connection between GUI and service.

If the same application (GUI) should also be enabled to communicate with a server that hosts the Business Logic over a HTTP/S Web Service interface, the generated products WebService and WebServiceClient can be used to implement an alternative technical service connection without changing the service implementation and the Application GUI. The WebServiceClient implements the same interface as the DatabaseClient and communicates with the generated WebService that is referencing the Business Logic module. By separating the interoperability layer into two components that are generated together, the physical distribution and network connection can be implemented in a way that does not influence the logical service interface.

Development productivity

An important characteristic of the ice.NET Service Builder is that it can be re-run with the same configuration anytime something in the service implementation has changed. Therefore, once correctly configured, it always keeps all interfaces and implementations of the interoperability layers up-to-date automatically and without any further programming effort.

Therefore the Service Builder performs the repetitve and tedious tasks that are associated with transferring changes in the business logic to technical service connection components. It relieves the developer from performing these maintenance tasks manually and reduces programming errors by automatically and consistently regenerating the code based on stable configurations and product templates.