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 {@link 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 {@link org.biomoby.shared.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 {@link org.biomoby.shared.MobyService 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 {@link 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 {@link 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 {@link org.biomoby.shared.parser} is closely related to the previous one because it provides Biomoby envelopes for data types defined in {@link 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.