How HydraExpress Uses Named Objects
The generated <servicecontextname>_objects.xml file defines the objects needed to run a service. For a simple service such as the DayOfWeek example, the required objects are the server implementation and the server skeleton, or binding. When instantiated, these objects are instances of rwsf::NamedObject.
NOTE: An object configuration file client-objects.xml is also generated on the client side for the message pattern notification. See Message Patterns in WSDL for more information.
The <servicecontextname>_objects.xml file is loaded by the Agent at startup. The server first creates the objects and then stores them together in a context object specific to the service, an instance of rwsf::NamingContext. This context object acts like a global registry that gives access to the objects.
Each <servicecontextname>_objects.xml file contains a series of <naming-obj> elements, each of which defines a named object. Each element contains two sub-elements: <naming-name>, which defines an object’s associated name, and <naming-class>, which defines the create method for instantiating the object.
This is the dayofweek_objects.xml file generated for the DayOfWeek example:
 
<?xml version="1.0" encoding="UTF-8"?>
<objects>
<!--
First register the user’s actual service implementation.
If the name of the implementation class changes, make sure
to also make the change here.
-->
<naming-obj> 1
<naming-name>http://localhost:8090/dayofweek/DayOfWeek</naming-name>
<naming-class>DayOfWeekPortServiceSample.createDayOfWeekPortTypeImp
</naming-class>
</naming-obj>
 
<naming-obj> 2
<naming-name>http://localhost:8090/dayofweek/DayOfWeekSkeleton
</naming-name>
<naming-class>DayOfWeekPortService.createDayOfWeekBindingSkeleton
</naming-class>
</naming-obj>
</objects>
 
//1 Defines the service implementation object.
//2 Defines the binding object.