Naming conventions for J2EE

Discussions

J2EE patterns: Naming conventions for J2EE

  1. Naming conventions for J2EE (35 messages)

    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).


    Threaded Messages (35)

  2. Naming conventions for J2EE[ Go to top ]

    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

  3. Naming conventions for J2EE[ Go to top ]

    I dont know how you deploy your applications but we usually dont deploy our source files ...
  4. Naming conventions for J2EE[ Go to top ]

    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?
  5. Naming conventions for J2EE[ Go to top ]

    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.

  6. Naming conventions for J2EE[ Go to top ]

    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?
  7. Naming conventions for J2EE[ Go to top ]

    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
  8. Naming conventions for J2EE[ Go to top ]

    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
  9. Naming conventions for J2EE[ Go to top ]

    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.
  10. Naming conventions for J2EE[ Go to top ]

    THANKS!

    IRL = In Real Life

    Mathias
  11. 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
  12. 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 !
  13. Naming conventions for J2EE[ Go to top ]

    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

  14. Naming conventions for J2EE[ Go to top ]

    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.
  15. Naming conventions for J2EE[ Go to top ]

    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
  16. Naming conventions for J2EE[ Go to top ]

    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.
  17. Naming conventions for J2EE[ Go to top ]

    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
  18. Naming conventions for J2EE[ Go to top ]

    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.
  19. Naming conventions for J2EE[ Go to top ]

    I like using the EJB suffix for ejbs, and keeping the BEAN suffix for regular non enterprise beans.
  20. Naming conventions for J2EE[ Go to top ]

    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?
  21. Naming conventions for J2EE[ Go to top ]

    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
  22. Naming conventions for J2EE[ Go to top ]

    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.
  23. Naming conventions for J2EE[ Go to top ]

    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.
  24. Naming conventions for J2EE[ Go to top ]

    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
  25. Naming conventions for J2EE[ Go to top ]

    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


  26. Naming conventions for J2EE[ Go to top ]

    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.
  27. Naming conventions for J2EE[ Go to top ]

    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
  28. Naming conventions for J2EE[ Go to top ]

    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
  29. Naming conventions for J2EE[ Go to top ]

    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
  30. Naming conventions for J2EE[ Go to top ]

    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
  31. Naming conventions for J2EE[ Go to top ]

    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.






  32. Naming conventions for J2EE[ Go to top ]

    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).

  33. Subpackage for implementation[ Go to top ]

    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.
  34. 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.
  35. Suggestions[ Go to top ]

    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.
  36. 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);
    }