What is the Trading Service?
The Trading Service is a sophisticated mechanism for locating server objects based on a description of requirements, rather than simple names. Objects register their services with the Trading Service, specifying a set of property values that describe the service that they are offering. Other objects can use the Trading Service to locate a server that provides a required service, based on these property values. The Trading Service matches the required service property values with those supplied by the servers when they registered.
Why should I use the Trading Service?
We often locate resources by searching for them not by their name, but by searching for a resource that can provide a particular service to us. For example, we look for a builder who can repair the roof, or for a printer that can print a document in color, or for a telephone service provider with cheap long distance calls. Rather than searching through the telephone white pages until we happen upon a building firm we recognize, we reach for the yellow pages and call on a business listed in the Building section. The Trading Service is similar to the yellow pages; it allows objects that can provide a service to register their abilities and it then allows clients to locate those services by describing the functionality they require. From then on, the client deals directly with the service provider object.
While the Naming Service provides a simple mechanism to locate objects ('services') by a name, this can quickly become unmanageable. For example, consider a system that manages printer queues. We can partition the printers into postscript and non-postscript printers. This is easy to model in a hierarchical manner using the Naming Service. However, if we also want to categorize printers by other capabilities, e.g. color or black and white printing, this becomes more complex. If you then add further categories, such as ink jet or laser printers, the hierarchical model very quickly becomes too complex to manage. Imagine the hierarchy levels that would be needed to categorize printers with varying throughput speed (in pages per minute) this can range from 1 to more than 16 pages per minute! Using the Trading Service, we would define a service type of 'printer' and specify properties that will allow us to categorize the different printers e.g.
mandatory property boolean postscript;
mandatory property short ppm; // Pages per minute
readonly property Boolean colour;
readonly property Boolean laser;
This allows any Trading Service user to query for a printer service based on the printer properties e.g. 'postscript == TRUE and PPM> 6'. You can also specify the order in which the matching service offers are returned. For the above example, you may want the printer service offerings listed by their throughput speed (PPM). You would specify this ordering as 'max PPM in the query return order criteria. Therefore, the Trading Service offers an object location facility that is more sophisticated than that offered by the Naming Service. The ability to search for objects on multiple criteria and to control the order of the returned matches greatly increases the flexibility and usability of the Trading Service.
What is the latest version of the Trading Service?
Version 4.x of OpenFusion contained the following functionality
- Full implementation of mandatory and optional parts of the OMG's Trading Service specification, including all interfaces (full-service trader), complete trader constraint language, and service type repository.
- Configurable caching and purging policies.
- Automatic garbage collection.
- Service replication across multiple databases.
- Deployment in clustered server environments for load balancing and failover. A number of default load balancing policies are included.
- Highly performant and scalable multithreaded implementation.
- Persistence of service type and offer data to commercial databases.
- Dynamic instrumentation of service type and offer counts.
Version 4.x contains additional configurable parameters to allow users to dynamically tune the dynamic operations of the OpenFusion Trading Service providing more options for reliability and scalability.
Support for database connection pooling has been added allowing database persistence schemes for the service offers to be reliably and flexibly deployed.
Support for JDBC 2.0 drivers in latest versions of databases (Oracle, Sybase, Informix, SQL Server) has also been added to take advantage of new features in JDBC 2.0 such as two-phase commit.
A number of additional features are provided to significantly improve the performance of the OpenFusion Trading Service, these include:
- Speed improvements with write cache.
- Improved multi-user access, more robust implementation.
- Improved offer search algorithm.
- Optimization of persistence mechanisms
- Which significantly improves performance when writing and retrieving offers.
- Support for latest POA ORBs
- OpenFusion 4.x allows interoperability and federation of the CORBA Trading Service across VisiBroker, Orbix and Orbacus platforms.
- Ability to output diagnostics information via HTTP.
- A new GUI tool for configuration and management is provided.
What is the difference between the Naming Service and the Trading Service?
The Naming and Trading Services are very similar in the services that they provide. These two services are the preferred ways to locate objects and bootstrap a distributed application. However, they do offer different levels of service. The following table illustrates these differences:
As the table shows, the services provide similar functions (i.e. locating objects), but they do it in very different ways.
What are the different types of Traders?
The OMG's CORBA Object Trading Service specification defines six different types of traders, depending upon the functionality that they support. The Trading Service specification defines five functional interfaces for a trader:
- Lookup allows clients to query the trader for offers
- Register allows services to be 'exported' (advertised) to the trader.
- Admin allows the trader property to be configured.
- Link supports the linking (federation) of traders.
- Proxy supports the delayed evaluation of offers and can be used to encapsulate legacy systems.
- The types of traders are determined by the interfaces that they support i.e.
The OpenFusion Trading Service implementation supports all five functional interfaces and is, therefore, a full-service trader.
How do I link Traders?
The operations on the Link interface allow traders to be linked together, so that a trader can make the offer spaces of other Trading Services available to its own clients. A link describes the knowledge that the trader has of the target trader. To link to a target trader, we must have a reference to the Lookup interface of the target and we will need to give the target trader a name. The link operation can also define policies for 'link following' i.e. when, and to what extent, the link should be followed in the resolution of a query e.g.
link.add_link( "Link to remote trader 2",
In this example, we have named the link as "Link to remote trader 2" and remote_2 is a reference to the Lookup interface on the remote trader. We have also set the 'link following' policy as: if_no_local. which means follow the link to the remote trader, if no local matches are found, always which means a client may override the default setting (above) to always follow the link. More details on linking traders can be found in the OpenFusion Developer's Guide.
What is the Service Type Repository?
The Service Type Repository is a centralized location for storing service type details. Service types can be added, modified, and deleted from the repository. The repository allows service types to be preloaded into a trader, so that the service definitions are ready for service providers (exporters) and clients (importers). The OpenFusion Trading Service implementation supports a Service Type Repository and provides utility tools to load service type descriptions from a text file. The service type descriptions can also be extracted from the repository and written to a text file. A single Service Type Repository can be shared by many traders.
How do I administer a Trading Service?
The Trading Service specification defines an Admin interface, which provides operations for configuring the service. These operations can be accessed programmatically or, for ease of use, they can be controlled via a GUI-based administration tool. The tool (called the Trader Manager) can be launched from the OpenFusion Administration Manager. It provides a intuitive user interface for configuring and managing a trader, and allows navigation to linked traders so that they can be managed in the same manner.
How well does the Trading Service perform?
The OpenFusion Trading Service has been proven to by far the most performant implementation available. OpenFusion 4.x has raised the bar further with significantly increased performance in all, and in some cases orders of areas and an order of magnitude improvement in performance over previous versions.
Visit OpenFusion Trading Service web page