The WebSphere Development Model


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 imposing too many technology assumptions on the implementation of your components – you certainly don't want to hard-code deployment policies into your business logic; these should be expressed through policy declarations during the assembly and deployment steps. On the other hand, the technology constrains of your deployment environment will help you understand which of the several component design patterns will work best for different parts of your application.

  • 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 Cell Manager (in a multi-server or clustered environment).

This more or less follows the program development pattern prescribed by J2EE. There are variations on this theme, and some of the process will depend on the tooling that you use. We will discuss the entire process in more detail in Chapters 3 through 6.




Professional IBM WebSphere 5. 0 Applicationa Server
Professional IBM WebSphere 5. 0 Applicationa Server
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net