This section describes the conventions HydraExpress follows when creating C++ classes and other supporting files.

In general, the class names are based on names extracted from the WSDL file. In using these names, HydraExpress removes any namespace prefix, ensures that the first letter of the name is uppercase, and translates characters that are not legal C++ identifiers to underscores.

Below is an abbreviated WSDL file illustrating the names that are used in creating class names. The example class names in the sections below use this WSDL.

HydraExpress creates a client proxy class for each wsdl:portType. The name of each class is based on the name of the associated binding with the string Proxy appended.

The WSDL file shown above would create one proxy class for each of the two portType elements (lines 1 and 4). The class names would be based on the binding names (lines 2 and 5), resulting in the classes GetSkiReportSOAPBindingProxy and GetInternationalSkiReportSOAPBindingProxy.

HydraExpress also generates a sample client implementation for each service defined in the WSDL. The implementation file names are based on the name attribute of the port element associated with each service, lines 8, 10, and 12 above. The client implementation files for this WSDL would be GetUSASkiReportClient.cpp, GetCanadianSkiReportClient.cpp, and GetInternationalSkiReportClient.cpp.

HydraExpress creates two server classes for each portType, a message handling skeleton class and an implementation base class. The port must have an associated wsdl:binding that contains a soap:binding element. In the typical case, the soap:binding element has a transport attribute that specifies the HTTP transport: transport="http://schemas.xmlsoap.org/soap/http".

The name of the skeleton class is based on the port binding name with the string Skeleton appended. The WSDL file shown above would create one skeleton class for each of the two portType elements (lines 1 and 4). The class names would be based on the binding names (lines 2 and 5), resulting in the classes GetSkiReportSOAPBindingSkeleton and GetInternationalSkiReportSOAPBindingSkeleton.

The name of the implementation base class is based on the portType name with the string Base attached. The WSDL file shown above would create one implementation base class for each of the two portType elements (lines 1 and 4 resulting in the classes GetSkiReportBase and GetInternationalSkiReportBase..

HydraExpress also generates a sample implementation class for each implementation base class. The sample implementation class derives from the base class, and its name is the base class name with the final Base changed to Imp. For the above example, these classes would be GetSkiReportImp and GetInternationalSkiReportImp.

When the WSDL file defines a notification or a solicit-response service, additional classes are generated. Assume the addition of the following definitions for a notification service to the example WSDL file:

The client-side classes for notification mirror the usual server-side classes. There is a skeleton class whose name is based on the binding name (line 2) with the string NotificationSkeleton appended. The resulting class name would be NotifySkiReportSOAPBindingNotificationSkeleton. Then there are an implementation base class and a sample implementation class whose names are based on the portType name (line 1), resulting in the classes NotifySkiReportNotificationBase and NotifySkiReportNotificationImp.

On the server side, there is just a proxy class whose name is based on the binding name (line 2) with the string NotificationProxy appended. The resulting class would be NotifySkiReportSOAPBindingNotificationProxy.

Generated classes contain one method for each wsdl:operation in the wsdl:portType that the class represents. The name of the method is the operation name. HydraExpress converts the first letter of the name to lowercase, translates characters that are not legal in C++ identifiers to underscores, and appends "_op" to the name if the result is a C++ keyword. For example, the generator creates a method named currentTemperature for an operation named CurrentTemperature. The generator creates a method named test_operation for an operation named test.operation.

The generator names the arguments to the generated methods based on the names of the wsdl:part elements within the wsdl:message elements for the operation. The generator converts characters that are not legal C++ identifiers to underscores, and appends the direction of the part to the name. The direction is determined as follows:

If all return values are inout parts, the method signature will have a void return type. Note that the complete signature of the method depends on the C++ type mapping, described in “Simple Type Mappings” and “Complex Types” .

When building an asynchronous client, be aware of possible naming collisions between your service operation names and the generated asynchronous service operation methods. Asynchronous methods are generated with a suffix start and end. For example, for the service operation getDayOfWeek, HydraExpress generates two asynchronous service operation methods getDayOfWeekStart() and getDayOfWeekEnd().

For more information, see “Asynchronous Method Naming Conflicts.”

For each project, HydraExpress either generates or copies from the <installdir>\conf directory a set of XML configuration files. For clients, these files are:

For servers, the files are:

Note: The variable <servicecontextname> comes from the soap:address location in the service’s WSDL document. For instance, in the following line:

The context is “dayofweek” just before the service name.

The default name for the generated makefiles is makefile and makefile_debug. You may customize the name of your makefiles using the -makefilename option when generating code. For more information, see “Customizing the Name of a Makefile.”