Package org.biomoby.shared

It contains components that are used from more than one (other) packages.

See:
Description

Interface Summary

Central	An interface to the Moby Registry.
CentralAll	A common interface to the classical features of a MobyRegistry (as expressed in Central) and to the cumulated (digested) contents of the Moby Registry (as expressed in CentralDigest).
CentralCached	A convenient interface combining together all methods for accessing the BioMoby registry and the handling its local cache.
CentralDigest	An interface to the cumulated (digested) contents of the Moby Registry.
LSIDAccessible
MobyObjectDecomposition

Class Summary

LSIDResolver	Implementation of LSID resolution for data and metadata.
MobyData	A container keeping input or output data types together with few other attributes.
MobyDataType	A container representing a data type used in the Moby registry (in the BioMoby speak it is called "Object Class").
MobyDataTypeTemplate	You probably don't need to be looking at this class.
MobyNamespace	A container representing a namespace used in the Moby registry.
MobyObjectDecompositionImpl
MobyPrefixResolver	The main purpose of this class is to provide default mapping from prefices we will use in the XPath statements built in the various client classes to URI's of XML namespaces.
MobyPrefixResolver.MobyNodeList
MobyPrimaryData	A container representing primary (both input and output) data as they are registered by services.
MobyPrimaryDataSet	A container representing a way how a named collection of various primary data types is used in a service.
MobyPrimaryDataSimple	A container representing a way how various primary data types are used in a service.
MobyRelationship	A container representing a name of a BioMoby data type and its relationship to another BioMoby data type.
MobyResourceRef	A container pointing to metadata available from a BioMoby registry.
MobySecondaryData	A container representing a way how various secondary data types are used in a service.
MobyService	A container representing a service.
MobyServiceType	A container representing a service type used in the Moby registry.
MobyUnitTest	A class representing a moby unit test.
NamespaceContextImpl	This class is used to provide namespace context for XPath expression evaluation in the Seahawk data mapping rules file, and includes default mappings for prefixes such as moby:
PrimitiveTypes
Utils	This is a set of several utility methods which may be useful for writing both registry and client code.

Exception Summary

MobyException	A general exception which can be used as a wrapper around other exceptions.
NoSuccessException	A specific exception indicating that a request should not be fulfilled because something was not correctly specified, or was not found.
PendingCurationException	A specific exception indicating that a request should not be fulfilled because registration or deregistration of an entity was not yet successful - but may be later.
SOAPException	This class is meant to be a implementation-independent wrapper around the exception classes provided by the underlying SOAP client used to run MOBY services.

Package org.biomoby.shared Description

It contains components that are used from more than one (other) packages. The bottom-line (or a bottom-rule) is: If one wants to run clients, it must be sufficent for him to pack all classes from org.biomoby.client and from this package only. If one wants to create a registry oriented component, it is enough for him to pack org.biomoby.registry and this package. And similarly for service providers which would pack org.biomoby.service and again this package.

Additionally this is a good place for putting here Java interfaces - assuming that they are expected to be used more generally. The cornerstone piece is the interface Central that defines how to access Moby registry without any knowledge of the used transport protocol (SOAP, XML, etc.). This interface uses several container classes representing pieces of the Moby mosaic.

Talking about a mosaic, it looks sometimes confusing what data containers we have here (and in sub-packages). Let's try to briefly explain them:

• The data containers located directly here (in org.biomoby.shared package, for example MobyService) were designed to carry information to and from Biomoby registries. Their names are a bit misnomer because they can be easily confused with similar data containers carrying real data to the Biomoby service providers.

• The org.biomoby.shared.data package deals with data containers travelling between clients and Biomoby service providers. They were designed by Paul Gordon and their usage is best explain in the Simple client document. The main idea is that the same data types are used for all services because they are designed as general as possible (its is a loosely-typed concept).

• The org.biomoby.shared.datatypes is similar to the previous one because it also contains containers for data exchange between the clients and Biomoby service providers. It was created by Martin Senger and its primary purpose is to be a part of code generators (see details in the Moses document. The package here has only primitive data types, but a data type generator is able to fill-in hundreds of data types from Biomoby registries - so developers can use strongly-typed approach.

• The package org.biomoby.shared.parser is closely related to the previous one because it provides Biomoby envelopes for data types defined in org.biomoby.shared.datatypes. It has classes for Biomoby Simples and Collections - where inside can sit containers from the previous package. Additionally, it has a Biomoby parser that can fill these containers from an XML.