Optimization Services Registry

To locate services in a decentralized serviced-oriented distributed system, software agents coordinate with each other and with registries. Some registries are general ones that keep information of all kinds of Web services, such as Universal Description, Discovery and Integration (UDDI). Others are specialized ones like the OS registry that only serves registration and discovery of Optimization Services. The OS registry knows all the registered services (solvers, analyzers, simulations) on the OS network by keeping their metadata information. The OS registry can be viewed as a light-weight server as no registered services are actually executed by this registry; instead clients directly contact the services in a peer-to-peer mode.

The Optimization Services registry serves the function of a search engine. But unlike the Internet search engines, there has to be a unique registry on the entire OS network to ensure quality of service. The OS registry operators make sure (e.g. through advertisement) that all communication agents know or can easily find out where the OS registry is. When a certain query is sent to the OS registry from a client, the OS registry returns the locations of the matched OS services and the client contacts each service directly at the provided location. On the opposite side of the “discovery” process is the “register” process. It is the OR software developer’s responsibility to submit the required information to, and get approved by, the OS registry, possibly through a mixture of automatic and manual procedures.

There are mainly two categories of registry-related OSP protocols; one deals with representation and the other deals with communication. To ensure that the OS registry only sends addresses of the services (especially solvers) that are of reasonably high quality, regulations are imposed when an OS-compatible service is to be registered in the OS registry. The following three OSP protocols are designed to make sure a solver is and continues to be well-described, live, reliable, and robust. Information about registered services in the OS registry includes three main categories:

• Entity information that is reported by service developers at registration, e.g. service and owner information, solver or simulation types and service locations. We call this category of information “entity” information to emphasize the information is relatively static. This is addressed by the Optimization Services entity Language (OSeL).
• Real-time process information that is either reported by the registered service (“push”) or detected by the OS registry (“pull”), e.g. how many optimization jobs are at the service server. We call the information “process” information to emphasize the information is dynamic. This is addressed by the Optimization Services process Language (OSpL).
• Benchmark information that is gathered separately by auxiliary benchmarker tools designated by the OS registry, e.g. general solver ratings and performance profiles. This is addressed by the Optimization Services benchmark Language (OSbL).
  

All the three types of information are kept in an XML database of the OS registry. As the OS registry is an open registry, to facilitate communication (especially discovery) with the registry, the structure and contents of the OS database are made public just like a yellow pages directory. The structure and contents in the OS database are specified in the OSRegistry.xsd schema.

To query the database, clients use the Optimization Services query Language (OSqL). In the OS registry implementation, an OSqL query is then converted to an XQuery that is executed against the XML database in the registry. The communication of sending the OSqL query to the OS registry is specified in the Optimization Services discovery Language (OSdL). In turn the clients get the location information from the registry that is listed as a sequence of URIs (or URLs); the syntax is specified in the Optimization Services uri Language (OSuL). The discovery mechanism is similar to sending an SQL query to a relational database.

On the other side of the discover process is the register process. Service providers join the registry with OSeL information. Optimization Services discovery Language (OSdL) specifies how this is done. During runtime, the Optimization Services registry periodically “knocks” on the registered services to make sure they are live and running and to get the OSpL information. OSdL also specifies how this is done. Service providers can also publish the entity, process, and benchmark information on their own Web site.