COMBINE - Platform specific model example
- Technology Discussion
- Detailed Design
- The Booking Editor Tool Design
- The Booking Viewer Tool Design
- The Subscription Editor Tool Design
- The Booking Service Business Service Design
- The Subscription Service Business Service Design
- EJB Implementation
Technology Discussion
This section discusses technology implementation choices for the various components identified.
|
Component | Interface name | Technology description |
| Booking Editor | Will be implemented as a Java application using Java 1.1 technology. The application will be downloadable through a web server, and is to be installed locally to support offline usage. | |
| Booking Viewer | Will be implemented as a Java applet using Java 1.1 technology. This applet will contain minimum functionality to support viewing of the master schedule. No modification, offline mode, import/export and save functionality will be supported. | |
| Booking Reports | Will be implemented as plain HTML pages. The pages will be dynamically served by a servlet. | |
| Booking Service | Will be implemted as a Java server using Java 2 Servlet technology. | |
| IBookingService | Will be implemented using the Servlet tunnelling framework. | |
| Subscription Editor | Will be implemented as plain HTML pages. The pages will be dynamically served by a servlet. | |
| Subscription Service | Will be implemented as a Java server using Java 2 Servlet technology. | |
| ISubscription | Will be implemented using the Servlet tunnelling framework. | |
| INotify | Will be implemented using the Servlet tunnelling framework. | |
| Email Browser | Will be provided by standard e-mail reader, e.g. Eudora or Netscape. | |
| Email Server | Will be provided by the company’s email server. |
Detailed Design
The Booking Editor Tool Design
Graphical User Interface
The client shall support a graphical user interface with 2 different views as depicted (simplified) in Figure 1. This drawing along with the discussion in section 0, which presents a BCE analysis of the use cases, gives the background for the transformation between the classes in the analysis model and the implementation classes in the design model. This transformation is shown in Figure 8.
Figure 1: GUI Schedule
BCE Analysis
Figure 2: Booking Editor use cases
The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the combined analysis of use-case 1, 2, 5, 7a, 15 and 16 shown in Figure 2. The result of the BCE analysis is shown in the diagram below.
Figure 3: Booking Editor BCE analysis diagram
A description of the BCE classes in given in the table below:
| BCE class | Description |
| BookingController | The ‘Booking Controller’ is the main controller for performing these use-cases. In the process it uses a few other controllers. |
| LoginController | The ‘Login Controller’ controls the entire login process. The user will enter username and password through the class ‘Login’ and the class ‘Access’ represents the access authorization. |
| AvailabilityController | The ‘Availability Controller’ controls the process of obtaining a list of the vessels best suited for a job. The class ‘Vessel Availability’ represents the data needed for this process. |
| SynchronizeController | The ‘Synchronize Controller’ controls the process of importing data from and exporting data to the global master schedule. |
| New Open Save Report VesselSelect | To create a new schedule, save a schedule and open a previously made schedule the classes ‘New’, ‘Open’ and ‘Save’ are used. These are “simple” dialog box type classes. Other “simple” dialog box classes are ‘Print’, ‘Report’ and ‘Vessel Select’. ‘Print’ will allow the user to specify the parameters used for creating a printed version of the schedule. 'Report' will allow the user to select among the different forecast and market-share reports available. ‘Vessel Select’ will allow the user to select among the vessels the ‘Availability Controller’ has found to be good candidates for the job. |
| Schedule JobForm SWO | The ‘Schedule’ is the main user interface. Figure 1 shows how this component will look. The other main user interface are the ‘JobForm’ and the ‘SWO’ which are the editors for the bookings and Seismic Work Order. |
| Bookings | The entity ‘Bookings’ represents both the locally stored schedules and the global master schedule. |
| Preferences | The entity ‘Preferences’ represents the users default parameters. Such parameters are which vessels he/she normally includes in the schedules and the time frame used. |
These BCE classes can be used in a further analysis of the use cases, in which sequence diagrams are used to describe the fulfilment of the use case scenarios. Examples of such diagrams are given below.
Figure 4 and Figure 5 show sequence diagrams for use case 1, Figure 6 shows a sequence diagram for use case 2, and Figure 7 shows a sequence diagram for use case 7a.
Use case 1: Book tender/lead
Primary scenario
Figure 4: Book tender/lead sequence diagram for primary scenario
Alternative scenario C
Figure 5: Book tender/lead sequence diagram for alternative scenario C
Use case 2: Update booking status
Primary scenario
Figure 6: Update booking status sequence diagram for primary scenario
Use case 7a: View schedule
Alternative scenario A
Figure 7: View schedule sequence diagram for alternative scenario A
BCE to Class Mappings
Figure 8: Booking Editor client class diagram from analysis
The diagram shows the mapping from the BCE analysis model to class design model.
Internal Class Design
Figure 9: Booking Editor internal design
The diagram shows the static relationship between the various implementation classes in the design model. The classes are the same as identified in Figure 8. The relationship to the User Service is also shown. This will be handled through an interface IUserService.
The User service will manage a set of user preferences. The service will handle a set of local schedules. The system will be able to simultaneously open a set of schedules and switch between them. The generic model for the schedules is based on the Activity Info model.
The ConfigurationService provides layout information and data type information used by the PropertyEditor. The PropertyEditor is a general editor used to edit any dataset of type PropertyList. The types IActivityIProject and IOrgUnit will all inherit from this type.
The Booking Viewer Tool Design
Graphical User Interface
The client shall support a graphical user interface similar to that of the Booking Editor tool and shown in Figure 1. As many components and structures as possible should be reused from that tool. However, the Booking Viewer tool should be as lightweight as possible so dependencies to unused code are undesirable.
The tool shall use the other lightweight tools (Booking Creator, Booking Modifier) to achieve the functionality of viewing, modifying the bookings in the global schedule.
BCE Analysis
Figure 10: Booking Viewer use cases
The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 7b, shown in Figure 10. The result of the BCE analysis is shown in the diagram below.
Figure 11: Booking Viewer BCE analysis diagram
A description of the BCE classes in given in the table below:
| BCE class | Description |
| BookingController | The ‘Booking Controller’ is the main controller for performing these use-cases. In the process it uses a few other controllers. |
| ViewScheduleController | The ‘View Schedule Controller’ is the main controller for performing these use-cases. In the process it uses a few other controllers. |
| LoginController | The ‘Login Controller’ controls the entire login process. The user will enter username and password through the class ‘Login’ and the class ‘Access’ represents the access authorization. |
| SynchronizeController | The ‘Synchronize Controller’ controls the process of importing data from the global master schedule. |
| Open | To open a schedule containing the desired vessels and the correct time frame, a “simple” dialog box type class ‘Open’ is used. The ‘Print’ class is also a dialog box type, which will allow the user to specify the parameters, used for creating a printed version of the schedule. |
| Bookings | The entity ‘Bookings’ represents in this case the global master schedule. |
BCE to Class Mappings
This section will discuss details regarding the Booking Viewer client tool.
Figure 12: Booking Viewer client class diagram from analysis
The 'Open' class in the analysis model is transformed into the 'New Dialog' class in the design model. The objective of the 'Open' class is to specify a set of vessels and a time frame, which is the same as the 'New' class in the analysis model of the Booking Editor.
Internal Class Design
Figure 13: Booking Viewer internal design
The diagram shows the static relationship between the various implementation classes in the design model. The classes are the same as identified in Figure 12. The relationship to the User Service is also shown. This will be handled through an interface IUserService.
The Subscription Editor Tool Design
BCE Analysis
Figure 14: Subscription Editor use cases
The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 12, shown in Figure 14. The result of the BCE analysis is shown in the diagram below.
Figure 15: Subscription Editor BCE analysis diagram
Figure 15 shows the result of the BCE analysis for the Subscription Editor.
Internal Class Design
Figure 16: Subscription Editor internal design
Figure 16 shows the internal design for the Subscription Editor. The relationship to the User Service is also shown. This will be handled through an interface IUserService.
The Booking Service Business Service Design
BCE Analysis
Figure 17: Booking Service use cases
The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 17 and 18 shown in Figure 17. The result of the BCE analysis is shown in the diagram below.
Figure 18: Booking Service BCE analysis diagram
Internal Class Design
Figure 19: Booking Service internal design
The diagram shows the static relationship between the various implementation classes in the design model. The diagram also shows that all layers will be accessed through an interface to provide for separation of concern. The BookingData is accessible through the IActivityInfo interface, which will be provided by the ActivityInfo resource service.
The booking data consists of vessels, companies, surveys, phases, business regions and subregions as described in the Business Model. The mapping of these business resources to the Activity Info model is shown in the diagram below.
Figure 20: Business Resource mapping to Activity Info Model for booking data
The Subscription Service Business Service Design
BCE Analysis
Figure 21: Subscription Service use case diagram
The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 19 and 21 shown in Figure 21. The result of the BCE analysis is shown in the diagram below.
Figure 22: Subscription Service BCE analysis diagram
Internal Class Design
Figure 23: Subscription Service component design
The diagram shows the static relationship between the various implementation classes in the design model. The diagram also shows that all layers will be accessed through an interface to provide for separation of concern. The SubscriptionInfo is accessible through the ISubscriptionInfo interface, which provides the subscription data.
EJB Implementation
This section describes the experiences gained with EJB technology as a result of implementing selected parts of the Survey Booking Application in EJB. This implementation phase has tested both 1) EJB 1.1 on IONA’s iPortal Application Server, and 2) EJB 2.0 on Sun’s J2EE 1.3 Reference Implementation.
Servlet Implementation
In order to extend the Survey Booking Application with EJB, it is important to have a clear understanding of the original implementation so that extension points where EJB fits in nicely can be identified. One important requirement with regards to this was to keep the original reference implementation unaffected, and to be able to run both the Servlet and the EJB implementation simultaneously.
Figure 24: Survey Booking Application component architecture
The deployment diagram above shows the scope chosen for the EJB implementation. Two target components, namely the BookingService and the ActivityInfo components, were identified as suitable EJB components. The implementation of these two components was done in two iterations:
- Implementation of an EJB version of the BookingService
- Implementation of an EJB version of the ActivityInfo
In addition to these two iterations, two other iterations were introduced, targeting both the EJB 1.1 and EJB 2.0 platform for the implementation of the ActivityInfo component.
Servlet communication
The communication details between the UserService component and the BookingService component is further elaborated in this section.
Figure 25: Design of servlet communication
The class diagram above shows the design for the servlet communication. The design makes use of the proxy and the delegation patterns. The WesternGeco servlet generation tools creates a Proxy class that is used by the UserService component, and a Stub class that is configured on the server that delegates method invocations to the actual BookingService component.
Figure 26: Deployment of servlet communication
The deployment instance diagram above shows the actual instances involved during the servlet communication. Two hosts, the client and the server, communicate using the TCP/IP protocol. The BookingServiceProxy and the BookingServiceServletStub communicates through HTTP-tunneling. The BookingServiceServletStub and the BookingService component communicate using plain Java method invocations.
BookingServiceEJB implementation
The first iteration consisted of developing an EJB version of the BookingService component.
Figure 27: BookingServiceEJB component architecture
The deployment diagram above shows the introduction of the new BookingServiceEJB component in the application architecture of the Survey Booking. As can be seen from the diagram, the original BookingService component is unaffected.
Servlet communication
In addition to the BookingServiceEJB component, we also needed to introduce a new servlet configuration for the EJB component.
Figure 28: Revised design of servlet communication
The class diagram above shows the revised design for the servlet communication. No changes were made to the Proxy class, so the client-side is unaware of any EJB server-side modifications. In order to run both BookingService versions simultaneously a new Stub class, BookingServiceEJBServletStub, was created for the EJB component. The Proxy class takes a URL parameter input in its constructor that decides which Stub class is being used.
The BookingServiceEJBServletStub only differs in respect to the original Stub class in how it instantiates the actual server object.
{
.
.
.
IBookingServiceRemote remote = null;
try {
Context initial = new InitialContext();
Object obj = initial.lookup("BookingServiceEJB");
IBookingServiceHome home = (IBookingServiceHome)PortableRemoteObject.narrow(obj,
IBookingServiceHome.class);
remote = home.create(props);
}
catch (Exception ex) {
System.err.println("BookingServiceEJBServletStub: " + ex.getMessage());
ex.printStackTrace();
}
return remote;
}
The code listing above illustrates how JNDI is used to create a reference to a remote EJB session bean that implements the BookingService business logic.
Figure 29: Revised deployment of servlet communication
The deployment instance diagram above shows the revised deployment instances. The BookingServiceEJBServlet stub communicates using RMI with the BookingServiceEJB contained in an EJBContainer (within an EJB Application Server).
BookingServiceEJB design
In order to make use of the current business logic implementation, the EJB bean was designed using the delegation pattern wrapping the original BookingService component.
Figure 30: Design pattern for wrapping EJBs
The class diagram above shows the design pattern used when developing the EJB wrapper component. The EJB bean implements the Java business interface. This approach allows for compile-time checking, since the EJB remote interfaces are only checked with naming conventions during deployment time. Furthermore, the EJB bean has an association to a business interface that it uses to forward method invocations to an instantiated business implementation object.
Figure 31: Detailed design of BookingServiceEJB
The class diagram above shows the detailed design of the BookingServiceEJB session bean class. The bean class has dependencies to its two EJB interfaces, and a relationship to the BookingService implementation class.
Deployment on IONA iPortal 3.0 Application Server
The BookingServiceEJB was configured as an EAR application and deployed on the IONA iPortal 3.0 Application Server, which has been chosen as the technical EJB platform in the COMBINE project.
The iPortal Application Server ships with server tools for deployment. Two of the tools used are:
- Application Administrator: This tool supports building EJB JAR files and EAR application files.
- Graphical Application Builder: This tool supports configuration of EJBs and EARs.
Figure 32: Application Administrator
The figure above shows two views of the Application Administrator tool. View one shows how one can create or add EJB JAR files, and the second view shows an editor for the deployment descriptor for the EJB container.
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1
//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'><ejb-jar>
<display-name>BookingServiceJAR</display-name>
<enterprise-beans>
<session>
<description>The initial values for this EJB have been deduced automatically.</description>
<display-name>BookingServiceEJB</display-name>
<ejb-name>BookingServiceEJB</ejb-name>
<home>marine.surveyBooking.com.IBookingServiceHome</home>
<remote>marine.surveyBooking.com.IBookingServiceRemote</remote>
<ejb-class>marine.surveyBooking.server.bookingService.BookingServiceEJB</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Bean</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor />
</ejb-jar>
The XML listing above shows the deployment descriptor for the BookingServiceEJB session bean.
Figure 33: Graphical Application Builder
The figure above shows a view of the Graphical Application Builder in which one can administrate references between and configure the various bean’s deployment settings.
ActivityInfoEJB implementation
The second iteration consisted of developing an EJB version of the ActivityInfo component.
Figure 34: ActivityInfoEJB component architecture
The deployment diagram above shows the introduction of the new ActivityInfoEJB component in the application architecture of the Survey Booking. The BookingServiceEJB component was modified so that a property decided whether it communicated with the ActivityInfo component or the new ActivityInfoEJB component. This allowed us to test the three different configurations of the implementation at run-time.
Servlet communication
We introduced a new servlet configuration for the ActitivyInfoEJB component.
Figure 35: Revised design of servlet communication
The class diagram above shows the new revised design for the servlet communication. Another legal URL parameter was configured for the BookingServiceEJBServletStub class. A boolean servlet property is associated with the two servlet configurations, so that the chosen URL decides which version of the ActivityInfo component implementation to use.
Figure 36: Revised deployment of servlet communication
The deployment instance diagram above shows the revised deployment instances for the ActivityInfo components. The BookingServiceEJB and the ActivityInfoEJB is located in the same EJBContainer.
ActivityInfoEJB design
In order to make use of the current business logic implementation, the EJB bean was designed using the delegation pattern wrapping the original ActivityInfo component. However, since the ActivityInfo component is passed as a reference to other components, a simple wrapper was not enough to integrate the new component transparently in the existing codebase. We also needed to wrap the EJB interfaces, so that only pure Java interfaces were exposed.
Figure 37: Design pattern for double-wrapping EJBs
The class diagram above shows the design pattern used when developing the EJB double-wrapper component. The EJB wrapper implements the Java business interface and has an association to a bean interface, which it uses to delegate method calls to the bean implementation. The bean itself, delegates the calls to the actual business implementation object, following the simple wrapping pattern described in the BookingServiceEJB section above.
ActivityInfoEJB with remote interfaces
The first implementation iteration for the ActivityInfoEJB component was targeted on EJB 1.1 technology using remote interfaces. However, this attempt proved unsuccessful. The following sums up our experiences with regards to this attempt:
- The ActivityInfo component represents a persistent activity graph with elements of type OrgUnits, Projects, Report and Activities:
- A simple EJB-wrapper implementation for EJB 1.1 failed with numerous CORBA exceptions.
- Debugging efforts gave the following explanation:
- EJB 1.1 uses RMI on local objects within the same JVM. The consequence of this is that RMI marshalling/demarshalling must be done when we pass the reference to the ActivityInfo activity graph. Since the activity graph contains recursive references, the RMI marshalling/demarshalling failed.
The solution to this problem was to:
- Completely rewrite the ActivityInfo implementation so that it conforms to the EJB 1.1 standard.
- Attempt to use local interfaces supported in EJB 2.0 on Sun’s J2EE 1.3 reference implementation.
Because of the poor performance results of the BookingServiceEJB implementation, alternative 1 was discarded. We felt that it was much better to gain experience with the EJB 2.0 standard, which adds support for local interfaces and relationship fields.
ActivityInfoEJB with local interfaces
The second implementation iteration was targeted on EJB 2.0 technology using local interfaces. The ActivityInfoEJB component was implemented using an ASCII file mapping for the persistent storage.
Figure 38: Detailed design of ActivityInfoEJB
The class diagram above shows the detailed design of the ActivityInfoAsciiFileEJB session bean class. The bean class has dependencies to its two EJB interfaces, and a relationship to the ActivityInfoAsciiFile implementation class. An ActivityInfoAsciiFileEJBWrapper class wraps the bean implementation and exposes only the IActivityInfo business interface.
Deployment on Sun J2EE 1.3 Reference Implementation
Since the IONA iPortal 3.0 Application Server does not support the EJB 2.0 standard, we were forced to try another product. Sun provides a free reference implementation of the J2EE 1.3 standard which incorporates EJB 2.0.
The BookingServiceEJB and ActivityInfoEJB were configured into one EAR application and deployed on Sun J2EE SDK 1.3.
The J2EE SDK 1.3 ships with a server deployment tool:
- Application Deployment Tool: This tool supports building and configuring EJB JAR files and EAR application files.
Figure 39: Application Deployment Tool – Building an EAR
The figure above shows a view of the tool in which one can create EJB jar files and add them to an EAR application. A SurveyBookingEAR application was created consisting of the two BookingServiceEJB and ActivityInfoEJB components.
Figure 40: Application Deployment Tool – Configuring an EJB
The figure above shows a view of the tool in which one can configure an EJB. As can be seen, the tool supports both remote and local interfaces.
Figure 41: Application Deployment Tool – Remote deployment
The figure above shows a view of the tool in which one can remotely deploy EAR applications on a target server.