Chapter 15. Deployment

Deployment Descriptors and EJB Roles

The deployment descriptor for an EJB is the ejb-jar.xml file included in the ejb-jar file used to deploy the bean. As you've seen in earlier chapters, you can control several characteristics of an EJB by using the entries in its deployment descriptor. From defining the transactional properties of methods to assigning security restrictions, you can change the behavior of a bean in many ways without having to change its code. This is the advantage of declarative control over being required to do everything programmatically. Having a declarative means to specify how your beans operate and relate to other objects and resources makes it easier to reuse them in multiple applications.

Most of what you define in a deployment descriptor has been covered in the various examples throughout the book, but this chapter covers it all in one place with more detail given on some of the options that are supported. Another difference here is that the elements of the deployment descriptor are discussed in terms of the role responsible for supplying them. Up until this point, it's been assumed that you were filling the roles of bean provider, application assembler, and deployer on your own. This will be true for you much of the time, especially when you're developing new components on projects that aren't too large for you to manage that way. Given that, you might think that the distinctions between these three roles don't matter to you. However, even when you must do the jobs assigned to every one of them, there are advantages to not forgetting about the EJB roles. Sometimes the need to act within a single role will be dictated to you, and other times considering the separate roles during design can help you create more flexible components even if you still have to do all the work.

If you purchase third-party EJBs or reuse those developed within your organization, you have no choice but to recognize the distinctions between the EJB roles. Here your responsibilities and options could be strictly defined because you might be working with beans whose code you can't change. When this is the case, the needs of the application assembler and deployer are more obvious (and definitely of more interest) to you. If you can't change the code for a bean you need to use, the only control you can exercise over it is through the deployment descriptor elements applicable to an application assembler or deployer. You might not face this on your initial EJB projects, but it's likely that this situation will become more common as the availability of third-party beans grows and your own organization begins building its inventory of reusable components from past projects.

Even if you're filling multiple EJB roles yourself, looking at the responsibilities of each one separately is still a good idea. If you put on your application assembler hat during the design process and think beyond the application you're currently developing, you're more likely to take steps to make your beans adaptable. This might include externalizing some key values used by a bean as environment properties or focusing on how to divide responsibilities between methods to make a bean more composable from a transactional sense. The same advice applies to considering how a deployer might need to adapt your beans to a particular environment as you're designing and implementing them. For these reasons, this chapter looks at the makeup of a deployment descriptor within the context of the EJB roles. Besides making you aware of the distinction between roles, this viewpoint will also make the structure of the descriptor elements more clear to you. As you'll see, some of the partitioning of the deployment descriptor elements is well aligned with the role boundaries. It also helps explain why some elements that are required to correctly deploy a bean are declared as optional by the DTD that applies to the deployment descriptor. What you'll see is that this is only done to defer their eventual definition to a particular role.