HydraExpress creates Web services that are highly configurable and able to handle runtime switching between configured components. The result is a dynamic system with the flexibility to implement complex services. Important aspects of the HydraExpress design include:

In the server-side architecture, messages arrive at a connector via some kind of transport, and are processed by one or more message handlers before being passed to the server implementation. If there is a return message, it passes through another chain of message handlers and out to the client through the same transport used for the incoming message. The message handler chains may or may not be symmetrical.

The transports shipped with HydraExpress are HTTP and HTTPS. These transports are configured in the file transports.xml on the server side and client-transports.xml on the client side. Configuring additional transports is a simple matter of adding an additional entry to these configuration files, and you can write and configure additional transports yourself.

Web service message handlers are equally configurable. The configuration files are <servicecontextname>_handlers.xml on the server side, and client-handlers.xml on the client side. In these files you can configure any number of message handlers and specify the order in which they should be applied to the incoming and outgoing messages.

For more information on configuring and creating transports and message handlers for Web services, see Chapter 14, “SOAP Message Handlers.”

The W3C WSDL Specification identifies four message patterns:

HydraExpress supports all patterns listed above, and generates the appropriate code automatically. HydraExpress determines the correct pattern for a given service operation by analyzing the definition of input and output messages for the operation in the WSDL file.

HydraExpress also supports asynchronous messaging. The request-response and solicit-response patterns are typically synchronous, but in practice there may be good business logic reasons for making the responses asynchronous, particularly in complex, orchestrated services. The one-way and notification patterns are inherently asynchronous at the service level, since there is no response to synchronize to, but they can be used together to create something very close to a synchronous interaction. For more information on asynchronous messaging, see Chapter 13, “Asynchronous Messaging.”

The objects that represent configured transports and message handlers are loaded into the Agent at startup based on the configuration file <servicecontextname>_objects.xml on the server side, and the optional client-objects.xml on the client side. It is this mechanism that makes all configured transports and message handlers available at runtime for dynamic switching. While this mechanism is set up for you automatically by the HydraExpress code generator for the services you create, it is also a generalized mechanism that you can exploit. For example, you could load an object representing a database connection, and your service application could use this object to obtain access to the database. For more information about named objects, see Chapter 16, “Named Objects.”

As noted above, any object loaded into the Agent at startup is available to your service implementation at runtime. This includes all transports and message handlers configured in transports.xml, client-transports.xml, <servicecontextname>_handlers.xml, and client-handlers.xml. Your service, for example, might need to send a response via HTTP or HTTPS, depending on user preference. Implementing such a flexible transport policy is straightforward, requiring only that the needed transports have been configured. It is also possible to selectively add to the message handler chain any message handler configured in <servicecontextname>_handlers.xml. For more information on runtime switching, see Chapter 14, “SOAP Message Handlers.”