Manageable Entities

Manageable entities provide CRUD facilities and a front-end view to managing entities. The EJB3 cartridge follows the same rules as in manageable entities.

There is very little you actually need to do. Just make sure you have the <<Manageable>> stereotype modeled on all entities that require CRUD features and their associated entities and the cartridge will take care of everything else. The following illustrates how we introduce manageable entities into our long-running example. Since manageable entities are driven via a web/console front-end, the example lists files from both the EJB 3.0 persistence layer and the Struts (using BPM4Struts) web layer.

images/org/andromda/test/16/a/uml.gif

  • Auto-generated source that does not need manual editing
  • Auto-generated source that should be edited manually
  • File that is affected by the modifications applied in this section

The EJB 3.0 related files are listed below. The ManageableServiceLocator is used by the Struts Action classes in much the same way as the ServiceLocator is used by the Service Delegates. Notice how the CarManageableService and PersonManageableService beans are defined int the ejb-jar.xml and jboss.xml deployment descriptors.

The CRUD related files are listed below. The EJB3 cartridge introduces the 4 CRUD related application exceptions for every entity. The web tier doesn't explicitly catch these exception, but perhaps will be available down the track. Take a look at the CarManageableServiceBase and PersonManageableServiceBase bean implementations to understand the business logic for implementing EJB 3.0 CRUD operations.

For further information on manageable entities, visit manageable entities for AndroMDA.

Security

In most cases, you probably want to secure access to the manageable front end. To secure your application follow the security section. The following additional changes will aid you to secure your manageable entities using the EJB3 cartridge.

  • Make sure you have also enabled the securityRealm property in the bpm4struts namespace of your andromda.xml application descriptor. This is on top of the securityRealm property in your ejb3 namespace section.
  • You must have the actor dependencies modeled on the manageable entities for the actors (representing roles/groups) that are authorised access to the DAO and manageable service layers.

    Typically, only administrators have access to manageable entities. Therefore, as a bare minimum, you can have an actor (i.e. Admin) with a dependency to the manageable entity. This will generate the security constraints in the DAO service layer and provide the web front end cartridge with the role information.

    The EJB3 cartridge has introduced a namespace property called manageableRolesAllowed. You must set this within your ejb3 namespace section of your andromda.xml descriptor file. This property takes the comma separated list of roles that are authorised to access the manageable entity services.

    In the trivial case where you only have the Admin actor/role, you will also define this property as:

    <namespace name="ejb3">
        <properties>
            ...
            <property name="manageableRolesAllowed">Admin</property>
            ...
        </properties>
    </namespace>
    
    However, when the application complexity requires several actor dependencies to entities, you have the flexibility to narrow the suitable actors/roles that have access to manageable entities, by specifying the manageableRolesAllowed namespace property.
  • Finally, the web.xml security and role elements will not be rendered unless you have modeled a front end application use case with the appropriate actor associations. Every use case must have one associated activity diagram. For the most trivial application, this activity diagram would consist of an initial state with a transition to a front end view action state. The generated JSP allows you to provide a 'cover' page for your manageable entity component pages.

Tips

You should assign one attribute of every manageable entity as a unique attribute. This is achieved by modeling the <<Unique>> stereotype on the attribute. As a result, it will display the unique attribute value for foreign key reference columns when listing entities, rather than the complete target entity property name-value pairs.

By assigning a unique manageable entity attribute, the readAll method of the manageable service base implementation avoids the use of left join fetch to retrieve collection association objects.

Be aware that manageable entities are currently available with the BPM4Struts cartridge only.

Next

Next you can learn about caching and clustering, click here.