When I started to develop a huge EJB project several months ago, I did not really care about the structure of the package and the naming conventions used within EJB. Last month, our project was so huge (+35 CMP beans + 20 session beans etc), we decided to change the entire naming structure.

We started looking on what others did. But, nowhere could we find more information on huge EJB projects. The only 'bigger' one we found was the Java Pet Store. It uses BMP, but it shouldn't really make a difference. So here are some thoughts on naming conventions, feel free to contribute your naming convention.

Entity beans:
com.companyname.projectname.ejbname.ejb.ejbnameEJB for the bean
com.companyname.projectname.ejbname.ejb.ejbname for the remote interface
com.companyname.projectname.ejbname.ejb.ejbnameHome for the home interface

E.G.:
com.etm.esupply.product.ejb.ProductEJB
com.etm.esupply.product.ejb.Product
com.etm.esupply.product.ejb.ProductHome

Session beans (for session wraps entity pattern):
com.companyname.projectname.ejbname.manager.ejbnameEJB for the bean
com.companyname.projectname.ejbname.manager.ejbname for the remote interface
com.companyname.projectname.ejbname.manager.ejbnameHome for the home interface

Model (for details object, bulk accessors and serializable objects):
com.companyname.projectname.ejbname.model.ejbnameModel for the details object
com.companyname.projectname.ejbname.model.serializableobject for a serializable object

E.G.:
com.etm.esupply.product.model.ProductModel
com.etm.esupply.product.model.Variation
com.etm.esupply.product.model.Attribute

A serializable object used within an entire project (e.g. Address), we use:
com.companyname.projectname.util.serializableobject

We also decided to devide the EJB's into several JAR files (using logical groups like customer.jar -> account bean, orders bean, profile bean) and divide the work load among the JAR's.

Our JNDI naming conventions are:
EJBNAME_EJB (e.g. PRODUCT_EJB), but I am thinking of changing this into ejbnameEJB (e.g. ProductEJB).

Mathias,

   Thank you for posting your naming conventions best practices. This little detail can often become the source of great confusion for beginners.

   One question: Since the home, remote and been class are being placed in the same package (thus same directory), doesn't this make it tedious for you when it comes time to deploy? All your interfaces (which need to be used by clients) are mixed in the same directory as the bean classes (which only belong in the ejb-jars), so what is your deployment process?

   On some projects I have worked on, we kept all of our interfaces in a separate package, for quick deployment. This to has its disadavantage though, as it becomes harder to separate EJB's in one application into separate jars.

Floyd

I dont know how you deploy your applications but we usually dont deploy our source files ...

We first compile everything with Ant (very recently Jbuilder 4), then we deploy the jar file.

I do not see the advantage seperating the bean class and its 2 interfaces.

"In this book, we place all the classes and interfaces associated with each type of bean in a package specific to the bean."
"The CabinBean class belongs to the com.titan.cabin package, just like the interfaces and primary key class."
(Enterprise Javabeans Second Edition, Richard Monson-Haefel)

I get the impression people think that this is not so important. But when working with +10 developers and you expect other parties programming on your API, this becomes in my opinion rather important because developers and 'client' programmers (e.g. JSP people) need a clear overview of the structure of the project.

Or am I completely off track here?

I just would like to mention that you might have problems with names such as com.etm.esupply.product.ejb.Product if you use RMI-IIOP and try to access your bean from a Java client. For more information, read this.

JB.

SilverStream Application server EJB eamples use the following convention:
       SB{Session Bean name} (remote)
       SB(Session bean Name}Home (home)
       SB(Session bean name}Bean (bean) for session bean,

change SB to EB for Entity bean.
does this make sense?

Mathias,

Here is the rules I use to define the Java packages:

1-- First level: re-use
The first criteria to define the Java packages is the re-usability level:
com.acme.fmk : contains reusable framework, abstract classes
     This package contains generic code.
com.acme.project1: contains application specific code.

The code in com.acme.fmk is re-usable if it does not import any packages from com.acme.project. (client-server relationship between packages).


2-- Second level: Logical architecture layers
Rule: "The Java packages must be compliant with the layered architecture".

If you design your system architecture with the following logical layers in the EJB container:
    - Service (Stateless Session EJB)
    - Workflow (EJB or not)
    - Persistence (for BMP, or non EJB workflow)

You must define 1 Java package per layer:
    - com.acme.project1.service
    - com.acme.project1.workflow
    - com.acme.project1.persistence

Because your code will be based on classes in the Framework, the framework usually use the same package organization:
    - com.acme.fmk.service
    - com.acme.fmk.workflow
    - com.acme.fmk.persistence

The classes in the package com.acme.project1.service will import the package com.acme.fmk.service.


3-- Using Java packages to partition the system
Each layer can be (if needed) splited into sub packages:
    - in com.acme.project1.service:
        create 1 package per use case.
    - in com.acme.project1.workflow:
        create 1 package per business domain
    - in com.acme.project1.persistence:
        create A package per business domain

Remark1:
--------
When you create an EJB such as com.acme.project1.workflow.Account, you must put the EJB implementation in a sub-package:
   - com.acme.project1.workflow.Account
   - com.acme.project1.workflow.AccountHome
   - com.acme.project1.workflow.bean.AccountBean

Remark2:
--------
For the deployement, an EJB module (JAR file) will contains a java package, such as service.jar or workflow.jar.
you can create coarse or fine grained EJB modules.

Tibo
Valtech

Thibault,

Here are some questions/remarks on your rules:
- "Persistence (for BMP, or non EJB workflow)", do you mean only BMP or CMP beans? And why put non EJB workflow there?

- "..you must put the EJB implementation in a sub-package", can you tell my why you do this? Only for logical reasons?

Can you please include some IRL examples? :)

TIA
Mathias

Hi Mathias,

> Here are some questions/remarks on your rules:
>- "Persistence (for BMP, or non EJB workflow)", do you
> mean only BMP or CMP beans? And why put non EJB
> workflow there?
The persistence layer supply the basic CRUD services to make the business entitites persistent.
  - If the busiess entities are CMP, this layer is generated
    by the container or by an O/R mapping tool such as
    toplink or cocobase.
  - If the business entities are BMP, this layer contains
    the DAO (Data Access Object) which contains the SQL
    code (do not put the SLQ code in a BMP entity).
  - If the business entities are not EJBs, but regular,
    non distributed Java classes, this layer contains also
    the DAO. This is what I mean by non EJB workflow: the
    workflow code goes to com.acem.project1.workflow, but
    the SQL code goes to persistence.

The persistence layer is usually Stateless.

> - "..you must put the EJB implementation in a sub-
> package", can you tell my why you do this? Only
> for logical reasons?

1- import com.acme.project1.workflow.* should import only the public interfaces of the component, not the implementation.

2- You can have a better control of the scope of the changes with configuration management. If nothing change in the workflow package, the component interface did not change.

> Can you please include some IRL examples? :)
What IRL means?

Tibo.

THANKS!

IRL = In Real Life

Mathias

Thibault,

I like the idea from your package-structure, of using logical names of the packages, "services", "workflow" etc. instead of names like "ejb", "entity", "session" and prefixes "EB", "SB". In my opinion the client does not want to know, and does not need to know how you component is implemented.

But could you describe the reason for Remark 1?

<snip>
Remark1:
--------
When you create an EJB such as com.acme.project1.workflow.Account, you must put the EJB implementation in a sub-package:
   - com.acme.project1.workflow.Account
   - com.acme.project1.workflow.AccountHome
   - com.acme.project1.workflow.bean.AccountBean

</snip>

If one of your ejb-methods returns a user-defined serializable object (ex. MethodResult), I would place this object in the same package as the Home and Remote-interface. By putting the implementation bean in another package, you cannot use any package-level methods to fill the result-object with data.

Is there actually a point of having a separate framework package, could not this be direct below the com.acme packages:
com.acme.fmk -> com.acme

Which gives:
    - com.acme.service
    - com.acme.workflow
    - com.acme.persistence

Andreas

See the mail I post for Mathias.

> If one of your ejb-methods returns a user-defined
> serializable object (ex. MethodResult), I would place
> this object in the same package as the Home and Remote
>-interface. By putting the implementation bean in another
> package, you cannot use any package-level methods to fill
> the result-object with data.
The StateHolders (serializable objects) goes in the same package as the home and Remote: the bean implementation need to import this package.
All the classes and interfaces known by the client goes to the package com.acme.project.workflow. The "EJB private classes", or implementation goes to com.acme.project.workflow.bean.

An an advantage of this design is for the configuration management: you can easily control the scope of your modifications.

> Is there actually a point of having a separate framework > package, could not this be direct below the com.acme
> packages:
> com.acme.fmk -> com.acme
> Which gives:
> - com.acme.service
> - com.acme.workflow
> - com.acme.persistence
It's also possible. But I prefere use com.acme.fmk to stay consistent with the "split-package-by-re-use-level" principle. com.acme.fmk, com.acme.project and so on.
The deployement is much easier: you just put the classes com.valtech.fmk in the CLASSPATH of the J2EE server and deploy the EJB.

cheers,
com.valtech.Tibo !

Hi Tibo,

I have a question on remark 1.

If the implementation and interfaces are in different packages, does the ejbc compiler follow the convention and put stubs in the interface package and the generated server code in the implementation package?

i.e. can you guarantee that com.myBean.* will only contain the interfaces and that com.myBean.bean.* will contain all the implementation and generated code after deployment ?

Many thanks.
Carl

Carl,

The WLS ejbc compiler put the stub and generated code in the package of the bean implementation, so all the generated code will go in the sub-package mybean.bean .
I not sure it's true for all of the J2EE servers.
I just use it on BEA WLS.

Tibo.

Hi Tibo,

Thanks for this.

My follow-up probably shows up my lack of understanding of RMI :-(

If my client (servlet, say) is on a different server to the EJB, then I think you would need to produce a client JAR containing the interfaces AND the stubs, which come from different packages.

Therefore, although the client only sees the interfaces in package x, the client JAR will also need the stubs from x.bean.

My worry is that the interface/implementation separation is not necessarily the same as the client/server separation and that may lead to confusion.

How wrong am I ?

Cheers
Carl

Carl,

The proxy implement the remote interface wich is located in the public package.
The implementation of the proxy (the stub) will be located in the private package (.bean), but it does not matter because you never access the proxy class implementation in your code.

So, it's ok !

Tibo.

Hi Tibo,

What about run-time?

If a developer on machine A is writing servlets to call EJBs being developed by another developer on machine B, then
developer on A will need the interfaces of the EJBs on the classpath. The code on machine A should then compile.

Now, when the servlet runs, the client will actually call a proxy to the EJB via the interfaces. Where is the proxy class?

It either has to be on machine A in a JAR on the client's classpath J2EE TechDocs or the client needs to set up the RMI codebase to the server on machine B, so that the stub can be downloaded.

My concern in all of this was that a deployer/administrator could mirror the naming convention in their deployments, and miss out the stubs; i.e. they would look at the imports, see that the servlet imports x.y.bean.*, and just include those classes in the client JAR.

I think your convention is good, but should advocate care at deployment time.

Cheers
Carl

I personally like yours:
com.companyname.projectname.ejbname.ejb.ejbnameEJB for the bean
com.companyname.projectname.ejbname.ejb.ejbname for the remote interface
com.companyname.projectname.ejbname.ejb.ejbnameHome for the home interface

but I reverse the ejb and ejbname, use "Bean" as the bean's suffix instead of "EJB", and use Iejbname for the business interface.

I like using the EJB suffix for ejbs, and keeping the BEAN suffix for regular non enterprise beans.

I don't care for this actually. Aside from the problems that this creates with IIOP (see earlier post), why create a package that is restricted to having only one EJB in it (only four classes to a package doesn't make sense to me). A package structure like the one below seems more flexible to me:

com.company.project.persistence.subSystem.className
  -- for all Entity Beans and Details objects
com.company.project.workflow.subSystem.className
  -- for all Session Beans
com.company.project.presentation.subSystem.className
  -- for all Servlets, Tag Libraries, Applets, etc...
com.company.project.util.subSystem.className
  -- for all common utilities and services

Details objects don't really belong with Entity Beans in my opinion, however, creating a separate branch for them also doesn't seem to make sense. Details objects and entity beans may also share a common business interface so in that respect it is nice to keep them together.

This structure also gives you the flexibility to have common base classes that span subsystems (like bean adapters and the like) where they belong, directly below the subSystem level.

For those that don't like persistence, workflow, presentation, and util; try model, view, controller, and services; or storage, business, gui, and common.

I also know of no IDE that I know of appends "EJB" to the class name for the bean. Usually "Bean" is appended to the bean. As for the name for the business interface, I have never really liked any of the proposed ideas that I have seen. I don't like appending "Business" to the interface name since it is too long. I don't like pre-pending "I" to the interface name since you are now revealing your implementation in your name, breaking encapsulation. Any other ideas for business interface names out there?

> the business interface, I have never really liked any of the proposed
> ideas that I have seen. I don't like appending "Business" to the interface
> name since it is too long. I don't like pre-pending "I" to the interface name
> since you are now revealing your implementation in your name, breaking
> encapsulation. Any other ideas for business interface names out there?

I like the idea of naming the "business" interface with the simplest name, just like you would name any old Java interface. So we have a company.project.component.ejb.Service that is the "business" interface of a session bean, and then ServiceBean, ServiceHome, and ServiceRemote. These all clearly indicate what each type really is, and since conceptually clients deal with the "business" interface, it is named as simply as possible and with the logical name (not anything about implementation). Why append redundant info to it? You don't see that in "plain old" Java, like RunnableInterface or ActionListenerInterface.

     Eric

Where does the resuability come into play? I'm not new to java and OO, but I'm just started to learn J2EE. What if I built a web-based thin-client word processor as an applet that I could reuse from CMS to CMS? I certainly wouldn't copy the files for another project.. i'd just java a package like com.positiveedge.edgeedit where EdgeEdit.class was the applet class.

Can someone please explain the whole framework of a good directory structure for enterprise projects that use applets, lots of utility code, jsp's, ejbs, and everything else. I'm a tad bit confused and want to have something structured nicely but don't quite understand where I'll come into problems.

Hi. I'm a beginner to EJB, so pls bear with me if I'm asking qns that's obvious to everyone else.

In the naming convention you suggested (one example below)
<com.companyname.projectname.ejbname.ejb.ejbnameEJB for the bean>

May I ask, what does the "com" stand for ? Is it the same as the "com" in the web address, whereby we can use "gov", "edu" etc. where appropriate ?

Or does it stand for a different set of things ? If so, what are they ? (i.e. other than "com", what else is there ?)

Thanks for any clarifications.

It is the reverse name of the domain, so yes, it is the same as the "com" in the web address.

But our company is called ETM, our domain is etminternational.com, but that was too long to put in the package name.

Mathias

Hi math
I am working with "websphere (AE)3.02" and my database is oracle 8.1.6.Here i am getting the problems with EJB . Going to the problem , there all total 42 EJB's among them 6 are session and remaining 42 are Entity beans.
13 of these Entity beans are having File name 27 characters long (Ex: MDL_PhysDocPatieAssocEntity)
when i am starting my EJB container on Websphere 3.02
its trying to create table in database(ORACLE 8.1.6)
with 33 characters as a table name(ex:MDL_PhysDocPatieAssocEntityBeanTbl)
but in oracle there is a constraint on "length of table name"
 that is 30 characters ,i am getting "ORA.00972 Error of oracle" (identifier is too long). Is there any way to overcome this problem .
Pls respond asap.

Regards
satish reddy

A site that had a pretty comprehensive naming strategy for Java is at

http://www.ambysoft.com/javaCodingStandards.html

This particular document doesn't get EJB Naming, but if one does evolve it would be nice to see it added to the above document.

Mathias: I have used a pattern very much similar to yours.
At least for the Entity beans.
Not so surprisingly because I also looked at the Pet store example before I chose a naming pattern.
The biggest problem with it, as already pointed out by others: Don't use the same name for a class and a package. I had to rename my packages because of this, when I swapped server from Ejipt/JRun to Inprise.
My solution: I just switched my package names to their plural form.
Another problem which I in some sense see in some of the
replies is the need for dividing/structuring the packages
by two principles. One is the business-object principle,
like yours, the other is system-subsystem principle, e.g.
client side/server side. Therefore I made a division
hi up in the package structure:
com.company.product.entities
  - further structured into business objects
com.company.product.system
  - further structured into system parts, e.g client,
server, admin, web etc.

(Note: I use product name instead of project, because a product is more static. You may have several projects over time working with the same product)

The system package is for things that does not fit
into the business object modelling principle.
E.g. where do you put an applet, client application,
a resource mangager, system configuration object etc.

Along with the ejb sub-packages I used gui for GUI-classes
related to the same business object, and web for JSP-beans.

Another detail, also mentioned in one reply: "what is com?".
Not all companies have .com. Some have .gov .org .de .se .fr .no ....

So, finally an example:


se.apicula.showtime.entities.persons.ejb.Person
se.apicula.showtime.entities.persons.ejb.PersonBean
se.apicula.showtime.entities.persons.ejb.PersonDAO
se.apicula.showtime.entities.persons.ejb.PersonHome
se.apicula.showtime.entities.persons.ejb.PersonPK

(where PK is for Primary Key)

se.apicula.showtime.entities.persons.gui.PersonDialog
se.apicula.showtime.entities.persons.gui.PersonModel
se.apicula.showtime.entities.persons.web.PersonJSPBean


/Thomas Grönwall

in replying to the first post, entity beans and sometimes sessions beans are reusable. So putting the project name might not make sense.. for me.. i just copy and reuse

Hello everyone,

Thanks for all the great contributions. After some more project experience and these comments I changed my package structure to:

<b>com.companyname.projectname.modulename</b>
For all interfaces of the beans of a specific module on a project, all utility classes specific to this
module (eg data models (containers) like CustomerModel and CartModel) and the exception classes (eg IllegalLicenseTypeException and LicenseExpiredException).

E.g. com.etm.commerceworks.application.Country (Remote inferface of the Country Bean)
E.g. com.etm.commerceworks.application.CountryHome
E.g. com.etm.commerceworks.platform.CartHome
E.g. com.etm.commerceworks.platform.RuleActionList (rule container class)

<b>com.companyname.projectname.modulename.ejb</b>
For the actual bean implementations.

E.g. com.etm.commerceworks.application.ejb.CountryEJB
E.g. com.etm.commerceworks.platform.ejb.CartEJB

Each project also has an <b>application</b> and <b>util</b> package (com.companyname.projectname.application and
com.companyname.projectname.util), for storing application specific classes (e.g. main class) and utility
classes specific to this project (e.g. Constants class, with project name and copyright notice)

As for entity or session beans.....mostly session beans end with Manager (e.g. CustomerManager) and are used
to implement the entity facade pattern.
Other session beans I put in .application or .util.

As for PK generation, we use "EJB utilities" from Emmanuel Sciara (http://sourceforge.net/projects/ejbutils/).

Mathias

Ow yeah, for web applications i use:

com.companyname.projectname.servlets
com.companyname.projectname.filters

E.g. com.etm.nympha.servlets.GeneratorServlet
E.g. com.etm.nympha.filters.GZIPFilter

And if I have no .util package, and no other modules, I
use com.companyname.projectname.web for the other classes.

Mathias

PS I will soon post my Naming Conventions for JSP

Lot of very good inputs, however I think that the naming schema should include other construct specifics.

Background:
- we are mostly working, up to date with Session Beans,
- we have distributed dev. teams.

1) We make a distinction between the Business Interface and the Remote interface:

The Business Interface only includes the Business oriented signatures, the Remote interface include EJBs ancilliary signatures:
com.acme.bean.MyBusInterface.java // Business Interface
com.acme.bean.MyBusInterfaceRemote.java // Remote interface

When dealing with Session Bean we use the CORBAish "Mgr" suffix to document that the object is a "Facade":
com.acme.bean.MyBusInterfaceMgr.java
com.acme.bean.MyBusInterfaceMgrRemote.java

Home is Home :)
com.acme.bean.MyBusInterfaceMgrHome.java

We also include at that level classes that are required by the interface but that are not per say domain business object; for instance you will find there object that can hold a complex query entry, or collections that are exchanged between the client and the server.

com.acme.bean.MyQueryByExampleHolder
com.acme.bean.TheSpecificPickList

Interfaces are held at the bean's root level, but implementations are a level down, leading to a tree for every bean that is like:

com.acme.bean.MyBusInterfaceMgr
com.acme.bean.MyBusInterfaceMgrRemote
com.acme.bean.MyBusInterfaceMgrHome

com.acme.bean.remote.MyBusInterfaceMgrBean

com.acme.bean.stub.MyBusInterfaceMgrStub

The Stub version is always developed up-front to enable interface cinsumers to start testing their code, hence reducing dependancies.

The net gain is that at the bean's root level you find the code that is shared between client and server (the complete interface) and down below you find the various implementations (stubbed out in stub, or real in remote)

That also provides for supporting various implementations of the same interface.

I heavily support the approach to have 2 packages, one for the interfaces and one (level down - here it's called remote) for the Bean. This is not only for reasons of clearness, but also to manage package dependencies correctly: A client needs the interfaces (and the Stubs generated for/from them), but NOT the bean implementation. Especially, it does NOT need the packages that are needed by the bean implementation (e.g. the interfaces of entity beans accessed in the standard SB-EB separation pattern).

This suggestion made earlier was good. I am re-iterating it here, to make sure i have understood it well :

One package for every module interfaces.
One sub-package for every implementation.

So here is a example for the module user:

com.myproduct.user.User
com.myproduct.user.UserHome
com.myproduct.user.SuperUser
com.myproduct.user.SuperUserHome
com.myproduct.user.bean.UserBean (This is a subpackage)
com.myproduct.user.bean.SuperUserBean (This is a subpackage)

This way the ONLY package we need to deploy on the client ( with servlets code) is :
com.myproduct.user

You DO NOT have to give the sub-packages like com.myproduct.user.bean

This way the separation is neat.

So, all interfaces go here :

com.myproduct.user.User
com.myproduct.user.UserHome

Implementations go here :

com.myproduct.impl.user.User
com.myproduct.impl.user.UserHome

This way you avoid the kind of sub-packages i described earlier.
You can just take ignore the impl packages, take all other packages and deploy on the client - side.

The idea here is to separate what needs to go to the client side deployment from what needs to be with server side deployment.

Hi,

The project that we are currently executing has 70 CMP bean's / 10 Session beans and more than 600 pure java objects (Value/DAO/Actions/ActionForms).

The naming convention we are following is as follows:

For Entity and Session Beans:
com.(companyName).(divisionName).apps.(applicationName).ejb

e.g,
com.seagull.wo.apps.koc.ejb.UserHome
com.seagull.wo.apps.koc.ejb.User
com.seagull.wo.apps.koc.ejb.UserBean


For Java classes:
com.(companyName).(divisionName).apps.(applicationName).(moduleName).objectType.className

com.seagull.wo.apps.koc.packager.dao.BuildPackageDAO
com.seagull.wo.apps.koc.packager.value.BuildPackage
com.seagull.wo.apps.koc.packager.action.BuildAction

Though the package naming is same we build them as different JARS,i.e., one for entity beans, one for session beans, one for SOAP components, one for java classes.

This helps us to differentiate in all the components involved as they are in different JARs and the naming convention helps to identify the type and other details.

We carefully thought about some good conventions and did prove them in many projects.

1. We use a prefix to determine the bean-type "S" (Session), "E" (Entity) and "M" (MessageDriven). E.g. if you have a sessionBean for persons and an entityBean for person we name them
SPerson
SPersonBean
SPersonHome
SPersonLocal
SPersonLocalHome
EPerson
EPersonBean
...

2. We put the interface in another package than the bean-implementation. Only with this method you are able to make an alternative implementation without affecting existing classes or packages.

de.<company>.<division>.<project>.<subProject>.group.ejb interfaces

de.<company>.<division>.<project>.<subProject>.apps.server.ejb implementation

This method provide the ability to add some alternative Implementation by adding a Package like de.<company>.<division>.<project>.<subProject>.apps.server2.ejb

3. We use - wherever possible - the names of the Home-Class as JNDI-Name. So we are aware of duplicate names and everyone can quickly find the approbiate bean-documentation. If we need the same home-class for several beans/implementations we add a suffix to the jndiName

4. We do not call beans directly from client-code. We define some technology-neutral Interfaces for the needed business-methods each throwing a general "TechnicalException" (in addition to business-exceptions). We use an xml-File to map these Interfaces to real Implementations. These Implementations could access the services through ejb-Remote, ejb-Local, WebServices etc. This can be configured by changing the xml-File so the client-Code is not affected.
The several ways to access a service use several exceptions. We wrap them in the TechnicalException so the Client knows there has been an error accessing the service and also has access to the underlying reason without "knowing" the technology.

If the client needs a Server it defines a class namened ServiceAccess with static method returning the implementations.

e.g.:

public static final IPersonReadAccess getPersonReadAccess() throws TechnicalException {
  return (IPersonReadAccess)ServiceAccessFactory.getInstance().getImplementation(IPersonReadAccess.class);
}