3.3 ebXML Registry/Repository

The ebXML Registry/Repository can be viewed as a database. The original idea has envisioned a distributed ebXML Registry/Repository. The Repository is where the data gets stored (the physical database). The Registry on the other hand is were users query, retrieve and upload data. The Registry is like the interface of the Repository. The Registry itself is connected to the Repository in the background. There are a lot of different functions of these two ebXML entities.

There are different objects which have to be stored in the Repository. Beginning with the smallest entities these objects are the Core Components, the aggregated Core Components up to the Business Processes, Business Process Information Meta Models, Business Documents, Collaboration Protocols Profiles, Collaboration Protocol Agreements and more (some of these parts are explained in later chapters). These objects do not have to be in XML.

The ebXML Registry Services Specification v1.0 [13] has all the details of the ebXML Registry/Repository. The ebXML Registry Information Model v1.0 specification [12] deals with how the data is stored in the Registry/Repository, how versioning is done and how data can be updated, extended and deleted.

The ebXML Registry architecture is based on a client-server architecture. The communication can be based on ebXML Messaging Service (see 3.7 for information on Messaging Service) or simply by HTTP. In case the client is using a common web browser the web server has to use the Registry Interface to communicate with the Registry itself. The ebXML Registry Services Specification defines Registry Interfaces to ensure, that Registry clients can communicate with Registry Servers. The first Interface is the Interface Registry Service which has only two methods to get a) an Object Manager and b) an Object Query Manager. The two important interfaces are the Object Manger and the Object Query Manager. The list of methods of these interfaces should allow the reader to get a picture of the usage of the interface.

• The Object Manager Interface has the following methods:
  • approveObjects()
  • deprecateObjects()
  • removeObjects()
  • submitOjbects()
  • addSlots()
  • removeSlots()
• The Object Query Manager Interface has the following methods:
  • getClassificationTree()
  • getClassifiedObjects()
  • getContent()
  • getRootClassificationNodes()
  • submitAdhocQuery()

It is worth mentioning, that an object can be either a Core Component, a Business Process or anything else.