The basic model for creating a WebSphere application involves the following steps:
Create a design model for your application – translating your business requirements into a set of design requirements and technology assumptions. A part of this process should consider the technology constraints that you will have to deal with in your deployment environment. On the one hand, you should avoid
Develop the application components and organize them in the web application and module archives that make sense for your application.
Define the deployment policies for your components – indicating the web defaults, transactional semantics, security assumptions, etc. for your application. In WebSphere, you would also specify the extended deployment policies supported by WebSphere at this time as well – such as access intent policies, session sharing policies, and so on.
Assemble these component JARs into Web Application Archives (WARs) and EJB Modules, and then assemble those into a J2EE Enterprise Application Archive (EAR). Assembly is often performed during your bean development cycle using WebSphere Studio Application Developer. It can also be performed as a separate step by an independent Assembler using the Application Assembly Tool shipped with the WebSphere Application Server. In addition, you can use an XML editor to edit the standard J2EE XML descriptor files stored in your WAR, EJB Modules, and EAR.
Generate the deployment code for your components – this often includes creating the mappings from your EJB properties to the schema of your database. If you want anything other than default schema mappings, you will have to perform deployment-generation in the WSAD tool – which also implies that you will have to perform at least partial assembly in the WSAD tool as well. You can still perform re-assembly in the AAT after you've exported your application from WSAD if you want to maintain this separation of roles. Likewise, an independent Assembler can use WSAD as their assembly tool in place of AAT.
Install your application to the WebSphere runtime – either directly on an application server instance (in a standalone environment), or through the
This more or less
A programming model should describe the entire model for developing, deploying, and maintaining applications in an information system. We will begin this by defining the roles of the various
In case it isn't already obvious, we should (re-)state here that WebSphere fully embraces Java and the Java 2 Platform, Enterprise Edition (J2EE) programming model. WebSphere version 5.0 complies with the J2EE 1.3 specification and, in fact, was the first major application server product to be certified for J2EE 1.3 compliance – that was with the Technology for Developers version of the version 5.0 product that was made available for Internet download in December of 2001.
J2EE defines multiple roles. These are:
In addition, the JSP specification defines the role of an
as someone who is responsible for assembling a set of static and dynamic content to build web pages that are relevant to their web site. And, to be complete, J2EE also defines the role of the Web Application and EJB container provider –
is responsible for codifying business and presentation logic in servlets, JSP pages and EJBs
The distinction between the servlet and EJB component models allows a clean separation of concerns between presentation logic and business logic. This distinction corresponds well to the differences in skills required for good encoding of how the business operates, its procedures and policies as encoded in the business components, and how internal users, business
J2EE presumes that many different component developers may contribute their components to an overall application – either in the context of a specific application or,
The component developer should set any deployment descriptors for their component that are needed to
The components built by a particular component developer (or team) are
needs to understand the semantics of the components provided by the component developer(s) and is responsible for assembling those components to form an enterprise application with a particular functional objective in mind. This includes identifying the components and collecting them in an Enterprise Application Archive (EAR) – a JAR file that contains all of the web application and enterprise component modules produced by the component developers, combined with a manifest and deployment descriptor information representing the deployment policies of the
The assembler is responsible for setting the deployment policies for application components – filling in any deployment descriptors that were not already set by the component developer(s) for the components in the assembly. In particular, the assembler should look for and attempt to resolve any discrepancies between the component deployment policies. For example, if you have a component that is implemented to make several calls on other components and is written to assume these calls will be commit-coordinated in a single transaction, the assembler should ensure that the components that are being called are set with deployment policies that will allow such external coordination. Any discrepancy between what the calling component expects and what the called component supports can lead to data integrity problems. The tool support for the assembler in WebSphere will be discussed further in Chapter 6.
The assembler is also responsible for mapping the essential state of an enterprise bean to a particular schema in their database. This, of course, requires the assembler to understand the target schema of the data system. If the application will be deployed into an existing system, the assembler should map to that schema – validating that the schema can be mapped reasonably. Often the assembler will have to work with the database administrator (DBA) to ensure the mapping targets are being interpreted correctly. If the application introduces data elements that do not already exist in the database, then the assembler will have to work with the DBA to add these elements.
A side effect of this collaboration is that the DBA may come to the conclusion that the application is not designed to fit
If, on the other hand, the target database does not already exist then the mapping process can be easier. The schema of the component's essential state can be used to generate a default schema for the data system. Again, the DBA should be consulted to help normalize the data system schema to ensure an efficient data system design.
A big part of what an assembler must do is to set, or validate, the security policies set for the components. This should start with the method permissions – the policies that state what user roles are allowed to access which
is responsible for installing the application into the runtime, configuring which application server(s) the application is to run in, and resolving the symbolic references to dependent components and resources to actual, physical resources in the configured topology. So, for example, the bean developer may use the reference
in their bean source code, and then declare the use of this reference in a deployment descriptor for their bean. If the actual
) are defined in the same enterprise application EAR, then the bean developer or assembler may resolve the reference binding to the actual
object's home in WSAD or in the AAT tool. This binding is then captured in the EAR file and will show up as the default binding in the deployment tools. If, on the other hand, the
bean is actually part of another enterprise application EAR, then the deployer will have to resolve that binding during deployment (
The deployer is responsible for finding an application server that can host the execution requirements of the application – for example, one that provides transactional integrity if this is what the application requires. WebSphere supports the entire J2EE programming model with a wide variety of configuration options. So, you can normally assume that any WebSphere Application Server instance can serve your J2EE application needs.
WebSphere supports a number of programming model extensions for sophisticated enterprise computing scenarios. Some of these extensions are only available to your application if you have installed the extensions provided in the Enterprise edition. You will have to ensure the application server instance supports these extensions if you will be deploying an application that uses them.
The system administrator is responsible for configuring the topology of the application server network. With WebSphere, this includes identifying each of the application server instances on each computer and in the network, establishing any clusters, defining the placement and configuration attributes of any resources that will be used by applications in the network, and ultimately, determining which application will run on which application server instance. In most cases you will want to configure your WebSphere network before you install the applications that will be hosted by WebSphere.
Once the application is installed, the responsibility of the system administrator is to monitor the system – watching for failures and performance bottlenecks, and correcting them as soon as possible. This includes watching for system alerts, evaluating the log files, testing the performance metrics, and monitoring the utilization of the system. A common problem that administrators of successful web sites will have to deal with is capacity monitoring and planning – recognizing when growing demand on the web site is starting to encroach on the available capacity of the computing resources, and
Before the application is allowed to go into production, the system administrator will often want to evaluate the security policies that have been set by the application assembler and deployer. The system administrator may be called on to authorize individuals or groups in your enterprise to perform certain user roles that grant them access to the component functions they need.
In this sense, the role of the system administrator is multi-
Defining distinct roles for each of the activities that contribute to the application development and deployment process is essential to maintaining a clear separation of concerns, and for ensuring an orderly delivery and setup for the application. However, in many cases, the same person will perform different roles. In this case, you should recognize the deployment phase that you are in, and perform the corresponding role with the tools provided for that role. Doing so will help maintain rigor in the development process.
It is nave to believe that the roles defined by J2EE are all there is to the world. In fact, a number of other roles will contribute to the success of your web sites and enterprise applications. We won't enumerate those here as the roles that will be relevant to you will vary depending on your circumstances. Key among these are the various administrators in your operations centers and business managers. Administrators are responsible for defining your topology, setting up your hardware and software platforms,