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).
-
Naming conventions for J2EE (35 messages)
- Posted by: Mathias Bogaert
- Posted on: November 04 2000 07:56 EST
Threaded Messages (35)
- Naming conventions for J2EE by Floyd Marinescu on November 04 2000 12:12 EST
- Naming conventions for J2EE by hector benalcazar on November 04 2000 14:25 EST
- Naming conventions for J2EE by Mathias Bogaert on November 04 2000 04:19 EST
- Naming conventions for J2EE by hector benalcazar on November 04 2000 14:25 EST
- Naming conventions for J2EE by Jean-Baptiste Nizet on November 06 2000 12:20 EST
- Naming conventions for J2EE by Jay Wang on November 06 2000 15:54 EST
- Naming conventions for J2EE by Thibault Cuvillier on November 06 2000 17:33 EST
- Naming conventions for J2EE by Mathias Bogaert on November 07 2000 04:04 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 07 2000 10:49 EST
- Naming conventions for J2EE by Mathias Bogaert on November 07 2000 10:55 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 07 2000 10:49 EST
- Naming conventions for J2EE by Andreas S. Brunvoll on November 07 2000 04:12 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 07 2000 10:57 EST
-
Naming conventions for J2EE by Carl Jones on November 10 2000 08:17 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 14 2000 12:17 EST
-
Naming conventions for J2EE by Carl Jones on November 17 2000 08:40 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 21 2000 07:56 EST
- Naming conventions for J2EE by Carl Jones on November 22 2000 08:48 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 21 2000 07:56 EST
-
Naming conventions for J2EE by Carl Jones on November 17 2000 08:40 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 14 2000 12:17 EST
-
Naming conventions for J2EE by Carl Jones on November 10 2000 08:17 EST
-
Naming conventions for J2EE by Thibault Cuvillier on November 07 2000 10:57 EST
- Naming conventions for J2EE by Mathias Bogaert on November 07 2000 04:04 EST
- Naming conventions for J2EE by Eric McIntyre on December 05 2000 17:24 EST
- Naming conventions for J2EE by josef betancourt on December 15 2000 12:40 EST
- Naming conventions for J2EE by Warren Janssens on January 13 2001 03:57 EST
- Naming conventions for J2EE by Eric Rizzo on February 14 2001 01:59 EST
- Naming conventions for J2EE by Ken Egervari on March 10 2001 07:15 EST
- Naming conventions for J2EE by Chih Hui Foo on December 31 2000 14:42 EST
- Naming conventions for J2EE by Mathias Bogaert on January 02 2001 05:46 EST
- Naming conventions for J2EE by satish reddy on January 04 2001 01:17 EST
- Naming conventions for J2EE by Mathias Bogaert on January 02 2001 05:46 EST
- Naming conventions for J2EE by George Pace on January 19 2001 12:52 EST
- Naming conventions for J2EE by Thomas Gr?nwall on February 13 2001 07:38 EST
- Naming conventions for J2EE by Ken Egervari on March 01 2001 17:06 EST
- Naming conventions for J2EE by Mathias Bogaert on March 31 2001 16:59 EST
- Naming conventions for J2EE by Mathias Bogaert on March 31 2001 17:05 EST
-
Naming conventions for J2EE by Charles B. on May 25 2001 05:15 EDT
- Naming conventions for J2EE by Harald M. Mueller on July 04 2001 06:10 EDT
- Subpackage for implementation by Jitender Bhatia on March 14 2003 08:21 EST
- Or Use a separate package for implementation by Jitender Bhatia on March 14 2003 08:23 EST
-
Naming conventions for J2EE by Charles B. on May 25 2001 05:15 EDT
- Naming conventions for J2EE by Mathias Bogaert on March 31 2001 17:05 EST
- Suggestions by Sunil Kashikar on February 05 2003 01:10 EST
- Conventions proved in many projects by Michael Wenig on May 27 2003 15:11 EDT
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Floyd Marinescu
- Posted on: November 04 2000 12:12 EST
- in response to Mathias Bogaert
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
-
Naming conventions for J2EE[ Go to top ]
- Posted by: hector benalcazar
- Posted on: November 04 2000 14:25 EST
- in response to Floyd Marinescu
I dont know how you deploy your applications but we usually dont deploy our source files ... -
Naming conventions for J2EE[ Go to top ]
- Posted by: Mathias Bogaert
- Posted on: November 04 2000 16:19 EST
- in response to hector benalcazar
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?
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Jean-Baptiste Nizet
- Posted on: November 06 2000 12:20 EST
- in response to Mathias Bogaert
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.
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Jay Wang
- Posted on: November 06 2000 15:54 EST
- in response to Mathias Bogaert
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? -
Naming conventions for J2EE[ Go to top ]
- Posted by: Thibault Cuvillier
- Posted on: November 06 2000 17:33 EST
- in response to Mathias Bogaert
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Mathias Bogaert
- Posted on: November 07 2000 04:04 EST
- in response to Thibault Cuvillier
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Thibault Cuvillier
- Posted on: November 07 2000 10:49 EST
- in response to Mathias Bogaert
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.
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Mathias Bogaert
- Posted on: November 07 2000 10:55 EST
- in response to Thibault Cuvillier
THANKS!
IRL = In Real Life
Mathias -
Naming conventions for J2EE[ Go to top ]
- Posted by: Andreas S. Brunvoll
- Posted on: November 07 2000 04:12 EST
- in response to Thibault Cuvillier
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Thibault Cuvillier
- Posted on: November 07 2000 10:57 EST
- in response to Andreas S. Brunvoll
But could you describe the reason for Remark 1?
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 ! -
Naming conventions for J2EE[ Go to top ]
- Posted by: Carl Jones
- Posted on: November 10 2000 08:17 EST
- in response to Thibault Cuvillier
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
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Thibault Cuvillier
- Posted on: November 14 2000 12:17 EST
- in response to Carl Jones
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. -
Naming conventions for J2EE[ Go to top ]
- Posted by: Carl Jones
- Posted on: November 17 2000 08:40 EST
- in response to Thibault Cuvillier
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Thibault Cuvillier
- Posted on: November 21 2000 19:56 EST
- in response to Carl Jones
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. -
Naming conventions for J2EE[ Go to top ]
- Posted by: Carl Jones
- Posted on: November 22 2000 08:48 EST
- in response to Thibault Cuvillier
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Eric McIntyre
- Posted on: December 05 2000 17:24 EST
- in response to Mathias Bogaert
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. -
Naming conventions for J2EE[ Go to top ]
- Posted by: josef betancourt
- Posted on: December 15 2000 12:40 EST
- in response to Eric McIntyre
I like using the EJB suffix for ejbs, and keeping the BEAN suffix for regular non enterprise beans.
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Warren Janssens
- Posted on: January 13 2001 03:57 EST
- in response to Eric McIntyre
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?
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Eric Rizzo
- Posted on: February 14 2001 13:59 EST
- in response to Warren Janssens
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?
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Ken Egervari
- Posted on: March 10 2001 19:15 EST
- in response to Warren Janssens
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. -
Naming conventions for J2EE[ Go to top ]
- Posted by: Chih Hui Foo
- Posted on: December 31 2000 14:42 EST
- in response to Mathias Bogaert
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.
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Mathias Bogaert
- Posted on: January 02 2001 05:46 EST
- in response to Chih Hui Foo
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: satish reddy
- Posted on: January 04 2001 01:17 EST
- in response to Mathias Bogaert
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
-
Naming conventions for J2EE[ Go to top ]
- Posted by: George Pace
- Posted on: January 19 2001 12:52 EST
- in response to Mathias Bogaert
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. -
Naming conventions for J2EE[ Go to top ]
- Posted by: Thomas Gr?nwall
- Posted on: February 13 2001 07:38 EST
- in response to Mathias Bogaert
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
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Ken Egervari
- Posted on: March 01 2001 17:06 EST
- in response to Mathias Bogaert
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Mathias Bogaert
- Posted on: March 31 2001 16:59 EST
- in response to Mathias Bogaert
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Mathias Bogaert
- Posted on: March 31 2001 17:05 EST
- in response to Mathias Bogaert
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 -
Naming conventions for J2EE[ Go to top ]
- Posted by: Charles B.
- Posted on: May 25 2001 17:15 EDT
- in response to Mathias Bogaert
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.
-
Naming conventions for J2EE[ Go to top ]
- Posted by: Harald M. Mueller
- Posted on: July 04 2001 06:10 EDT
- in response to Charles B.
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).
-
Subpackage for implementation[ Go to top ]
- Posted by: Jitender Bhatia
- Posted on: March 14 2003 08:21 EST
- in response to Charles B.
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. -
Or Use a separate package for implementation[ Go to top ]
- Posted by: Jitender Bhatia
- Posted on: March 14 2003 08:23 EST
- in response to Charles B.
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. -
Suggestions[ Go to top ]
- Posted by: Sunil Kashikar
- Posted on: February 05 2003 01:10 EST
- in response to Mathias Bogaert
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. -
Conventions proved in many projects[ Go to top ]
- Posted by: Michael Wenig
- Posted on: May 27 2003 15:11 EDT
- in response to Mathias Bogaert
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);
}