The structure of this document is based on a software architecture specification template by Donald Firesmith for the OPEN Process Framework.
The target audience for this document are:
Here is a graph that shows the top physical packages and interfaces and their dependencies. The graph was generated by
Pasta
The registry is entirely implemented in Java. It provides two
interfaces to access its functions: SOAP/HTTP and REST/HTTP. The HTTP
interfaces are implemented as servlets that are hosted by a web
container like Tomcat. The registry data is stored in a relational
database. The repository data is stored as files in the regular OS
filesystem.
The following sections describe the components of the registry server.
Implements the normative binding for SOAP/HTTP. The servlet checks
the authorization of the message sender, translates the SOAP message
into a registry operation and returns the result.
Implements a plain HTTP binding for the registry service. It uses an architectural style for creating requests called Representational State Transfer (REST). This style mandates how service calls and parameters are passed through HTTP. It also requires that the operations are stateless.
The servlet decodes the REST requests, invokes the corresponding registry operation and returns the result.
Provides the ebXML QueryManager filter query registry service. The
queries are translated to SQL queries and forwarded to the SQL Query
Manager component.
Provides the ebXML QueryManager SQL query registry service and
supports the execution of SQL queries. This component parses incoming
ebXML SQL queries and generates SQL queries that take the user
permissions into account.
Provides utility methods to authenticate users and check their
authorization. The ebxmlrr client provides a basic tool to maintain
users.
Implements a repository that holds the repository items. There is a
generic interface to the repository. The current implementation stores
all items in the file system.
This component provides a data access layer to a relational
database. It tries to use fairly generic SQL statements that are
compatible to the major databases. The database holds all registry items.
The server is deployed to a web container that supports the Java Servlet specification, version 2.2. The web container creates an instance of the servlet when a request arrives. After the request is processed, the instance gets recycled, i.e. it may get cached and reused or it is removed. When the web container is shut down properly, it discards all servlets after all requests were processed.
Ebxmlrr can pool database connections so that it does not have to
create a new connection every time that a request is processed.
All components in the server throw RegistryExceptions when an error
is encountered. Every component specializes the RegistryException for
every type of error. This helps to provide clearer error reports and
pinpoints the component that created the exception. All registry
exceptions are caught by the servlets and reported back to the client
through the ebXML status.
Errors that occur outside of the regular servlet operation, e.g. at
start up or shut down are logged by the web container and can be
monitored by the registry operator.
The registry server uses the Jakarta Commons Logging API to log all
events and errors. Every Java package uses its package name when logging
an event. The web container may use its own logging.
The Commons Logging API allows to configure the log implementation.
That enables the web container and the ebxmlrr server to write to the
same log.
Ebxmlrr distinguishes two data types that are stored persistently,
registry items and repository items. Repository items are the actual
business data, e.g. contracts, and registry items are metadata that
mainly serves to categorize the repository items.
Both registry items and repository items are managed through the
Life Cycle Manager. It provides methods to store new items, update
existing items and remove items.
The current repository implementation provides a generic interface to the repository but implements only a file-based repository. Every repository item is stored as a separate file. The Universally Unique Identifier (UUID) of the item is used as its filename.
Registry items are stored in a relational database. Ebxmlrr relies on data access objects (DAO) that provide an object-oriented interface to the registry items. Inside the DAO, the operations are translated into SQL statements.
The web container manages concurrent requests. It instantiates a new
servlet for every request which prevents thread synchronization issues
on that level.
None of the component interfaces contain state. All of the
interfaces are implemented as singletons that are instantiated in a
thread-safe manner. That makes access to the components thread-safe.
The DAOs use transactions by default. If an item is manipulated more
than once concurrently, one of the transactions fails.
The ebxmlrr core components may not be distributed. It would
probably be possible to access the database from more than one ebxmlrr
instance, however the file repository is not designed to allow access
from separate ebxmlrr instances. The SQL database may run on any host.
Ebxmlrr can only use one database instance.