Development Roles


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 participants in that process. This section will overview the roles defined by J2EE, and will go on to describe other roles in the overall development process that J2EE does not currently consider.

Roles Defined by J2EE

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:

  • Component Developer

  • Application Assembler

  • Application Deployer

  • System Administrator

In addition, the JSP specification defines the role of an Author 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 – otherwise known as the WebSphere Application Server for the purposes of this book.

Component Developer

The component developer is responsible for codifying business and presentation logic in servlets, JSP pages and EJBs components. The component developer should focus primarily on writing reusable assets that encapsulate specific business functions.

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 partners and customers access and interact with that business function. Consequently, the component developer role may actually be decomposed into several sub-roles corresponding to the different expertise and knowledge captured in different components of the application.

J2EE presumes that many different component developers may contribute their components to an overall application – either in the context of a specific application or, ideally, with an eye to how that asset can be reused in different applications. The developer will make reference to other components and resources that they depend on using symbolic names – mostly expressed as java:comp/env names in their code. For example, if you introduce a component that depends on, say, an Account object, you will look up that object's home in JNDI with something like java:comp/env/ejb/AccountHome.

The component developer should set any deployment descriptors for their component that are needed to convey assumptions or constraints embedded in the component. For example, the developer should declare any symbolic references that they used within their component implementation. If they've coded to make certain assumptions about the transactional integrity of the things that they call, these should be captured as well.

The components built by a particular component developer (or team) are composed into either a Web Application Archive (WAR) or a JAR file containing a set of enterprise beans referred to as an Enterprise Module. These contain either presentation components or business components and their related artifacts, respectively.

Application Assembler

The application assembler 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 assembled application.

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 efficiently into the existing database. In this case, the assembler may need to work with the component developers to adjust the design of the application to make it more efficient. Given this, the assembler should begin working with the application developers early in the design phase to ensure the highest probability of success.

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 methods of the component – and should conclude with making sure the relevant user roles are declared from the application. This will be discussed further in Chapter 13.

Application Deployer

The application deployer 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 java:comp/env/ejb/AccountHome in their bean source code, and then declare the use of this reference in a deployment descriptor for their bean. If the actual Account (and it's Home) are defined in the same enterprise application EAR, then the bean developer or assembler may resolve the reference binding to the actual Account 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 Account bean is actually part of another enterprise application EAR, then the deployer will have to resolve that binding during deployment (assuming that the Account application has already been installed and configured).

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.

System Administrator

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 projecting when additional capacity will be required.

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-faceted, involving configuration management, performance management, problem management, capacity management, integrity management and security management. We'll discuss more about the features of WebSphere that enable this management in Chapter 14.

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.

Additional Roles

It is na ve 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, interconnecting your networks, planning for and installing your applications, ensuring failover and recovery procedures, managing and planning the capacity of your systems, and so forth. Business managers are responsible for defining the business requirements for your applications, and for matching those applications to the business processes and policies. You may have other roles that factor into the deployment of your systems in your company.




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