WebSphere Enterprise Build and Test Guidelines for Component BrokerIntroductionConstructing or building applications using WebSphere Application Server Enterprise Edition (WAS EE) Component Broker (CB) is probably a little different from what you're used to. Because we have a complete infrastructural framework and programming model to work with, there are many things to consider at each step of the development process. One of these considerations is how to work with a team of developers to build a complex application, allowing parallel development and the reuse of common components or objects. For more detailed information on this topic, see Team Development Guidelines for Component Broker Applications. The focus of this guide is on the implementation phase of the application development process. The primary implementation tool that we use during this phase is Object Builder. Object Builder is the tool that guides us through the process of building a Managed Object along with other application components such as Homes, DLLs, Application Family Packages, and Data Objects. If you are not familiar with these components or would like a refresher, then check out A Nutshell Guide to the Component Broker Programming Model. Contents
Basic Concepts
RelationshipsThe basic object modeling relationships, such as association, aggregation, and inheritance, are fully supported by the Object Builder tool. When dealing with associations, we can fully implement 1:1, 1:n and n:n relationships with a variety of implementation options. The tutorials and guides describe how to use Object Builder when implementing these relationships. There is no silver bullet here. Complex relationships yield complex solutions. When implementing associations, there are several options that will be available depending on the Application Adapter Container being used; know and understand the container you will be using. Working with dependenciesIn general, dependencies are something to be minimized. We want to strive for the basic software engineering principles of low coupling and high cohesion. We want to keep our dependencies between Interfaces, Classes, and Applications to a minimum because whenever there is a dependency of one thing on another, it means that one entity cannot be used without the other one being present; that is, it becomes less reusable as a standalone component. Dependencies increase development and maintenance costs. Dependencies are created by the two basic kinds of relationships relationships, as discussed in the previous section, and dynamic relationships, which are also known as uses relationships. The static relationships are easily spotted in the Class Diagrams, whereas the dynamic relationships will be evident in the Object Interaction Diagrams of your Dynamic Design Model. The uses relationship is a little harder to spot because the relationship is dynamic and only appears at runtime, under certain conditions. Whenever you have a dependency between one or more objects, you need develop (at least up to the interface) the most independent object first. Thinking about this ahead of time will prevent aggravation later in your development process. Dependencies show up in several places when developing CB Applications.
Items 1 and 2 above are common problems in application development. There is nothing new to consider, just be aware of what kind of relationships youre working with and where you are in the development process. Item 3 merits further discussion. Managed Objects that are related to each other need to be in the same application family. Related, in this case, means associations and inheritance. Usage relationships across application families will work. Relationships can span applications but not application families. Application FamiliesOnce the number of application families is determined, then the next question is how many applications are needed. An application is one or more Managed Objects that do some piece of the application family function. Again, having one managed object per application is probably not the best idea. In a large 70 managed object system, for example, this would mean that 70 applications would have to be configured in systems management The application is the unit of distribution across servers. Therefore, if you don't want objects to ever be considered as separate distributable units, put them in the same application. Some objects have a little more coupling between them than the books might suggest is optimal. This means these objects are probably moving data structures between them. These are good objects to package into a single application. Another dimension of physical packaging to consider is that of serviceability or maintenance. How coarse or granular is the service going to be? If every managed object is an application, then it will be very easy to refresh the application to update a single managed object. Again, groupings are probably more logical and you'll probably have something in between. Rational Rose® to Object Builder BridgeThe Object Builder Bridge program is a tool that is provided as part of the CB Development Toolkit. The bridge provides a mechanism to export class definitions and relationships from a Rational Rose design model to an Object Builder Implementation model. Since the implementation is specific to the CB Framework, there are several implementation classes/objects, such as the Key and Copy Helpers that can be created at this time. The generation of these implementation-specific classes is optional and can be controlled by property settings in the Rational Rose tool. To learn more about installing, configuring, and using the Rational Rose Bridge, see Bridging Rational Rose to Object Builder and the on-line documentation that comes with CB. This setup only needs to be done once. Testing
Quick TestQuick Test is the first step in testing a Business Object. A comprehensive and complete test strategy must be developed for the overall application. The Quick Test tool provides a quick way to test the basic functionality of the business objects but should not be the only procedure for testing. The scripting and playback features of Quick Test can be used for some level of regression testing at the basic business object level. To develop useful and reusable Quick Test scripts, you should allocate time for experimenting with the capabilities of Quick Test and plan your scripts carefully. Use the User Acceptance Test Plan, developed during the analysis phase of the project, as a guide for your scripts. A good User Acceptance Test Plan will span use-case boundaries and exercise the capabilities of the system as the user will be expecting to use it. Comprehensive TestingThe test strategy should be graded, starting with the basic functionality on a dedicated, single-node test system without workload management, evolving through the more complex and realistic usage scenarios. There are logging, tracing, and debugging facilities available to monitor and capture information. These facilities can be enabled or disabled by the System Management facility. Services
If you are at the point in your project where youre trying to understand the Common Object Request Broker Architecture (CORBA) services that are available to you with CB and how to use them, then refer to the Component Broker Advanced Programming Guide. Each service is discussed thoroughly and examples of how to use them are provided. The following sections highlight some features that may not be readily apparent and provide information based on experience using the services. Event/Notification1. The Event/Notification service is transient. 2. A client cannot use the Push model of subscribing to events, there are no callbacks. QueryQueries are an integral part of any application that involves entities and business processing. Queries should be used as needed. Always use the evaluate and extendedEvaluate methods on the home if possible. At some point in development, queries need to be optimized. Its important to get as much of the query pushed down to the underlying data management resource (database manager) as possible. The query service also performs better when it has more direct mappings from the IDL types to the database types. Query is another good operation to run in an Application Object rather than in the client. In many cases, moving large data structures to the client from the server will be inefficient. For more information on this refer back to the discussion on Application Objects and the Design Guide. With the OO-SQL support in CB its possible to compose queries that do not return result sets of objects. The query may only specify a subset of all the attributes in the object or it may be a join between two different objects. In either case, instead of getting a result set of objects you will get a result set of data_array objects. Each row in the result set will be an array of the selected attributes. CachingThe caching service is implemented by the container. The application programmer does not have to do anything other than associate their business objects with the container that supports this service. If this option is available, it will be exposed to the developer in the Object Builder task of configuring the container. There are configuration parameters that can be manipulated for the System Management End User Interface. The general recommendation is that the Cache service should be used and that it should be used in default pessimistic mode for most cases. Read the documentation for details on when optimistic mode transactions should be used and when it's appropriate to configure and leverage the data cache to achieve a high-performance, dirty read capability. Finally, read carefully about the semantics of optimistic cache and write code around the transaction.commit() that knows what to do when a transaction is not committed because of a change in the underlying datastore that took place while the data in memory was also being changed. . ConcurrencyDon't use the concurrency service unless you have specific serialization requirements that aren't supported by the container configurations. In general, let the container manage your object for you as much as possible. Client Programming
WebSphere Application Server Enterprise Edition (Component Broker) is the IBM implementation of the CORBA II specification. As such, our client-server distribution model has been defined for us. The CORBA programming model specifies a lightweight client proxy that marshals method requests and sends the requests to a separate implementation object that may reside anywhere within the defined network. The implementation object is located using the Object Request Broker in conjunction with the Name Service. Because our method requests are marshaled into a standard format and sent across the network to the implementation object, we have the ability to write client programs in a programming language that is different than the actual implementation that will execute on the server host. With CB, we can write client applications using:
Each of these clients will follow a client programming model, which is described in the Component Broker Programming Guide. There are several standard tasks that must be done in all client programs. The syntax varies with the language, but the tasks are the same.
Software
Development Tools for Client Application Development
There are no software development tools that directly support the development of the client applications that will use CB Managed Objects. The CB tool set is focused on developing server side managed objects, and deploying and managing them in an Enterprise environment. The CB tool set will generate all necessary client files and executables that a client program will need in order to use the CB Managed Objects, for example, client DLLs and headers for C++ and client jars, and Java classes for Java. Issues Related to Client Programming
In the WebSphere programming model, servlets are used to run application function initiated from a Web browser, in the server space. In this situation, the servlet becomes the client of our managed object. This is a very popular programming model because it allows for a thinner client with fewer dependencies on the server architecture; for example, the ORB and/or RMI. Naming and Lifecycle Services
Check out the use of Factory Finders and Location Scopes. This information is provided by IBM
Corporation © Copyright IBM Corporation 1999-2000
|
|
Rational Unified
Process |