Chapter 2. Architecture of the commerce.connect products 17
to upgrade the hardware, software, or both. The minimum hardware requirements
obviously depend on the usage profile of the customer as well as the base WebSphere
Application Server requirements.
2.4.3 Functional architectural considerations
This section details current known functional requirements that may likely have a major
impact on the architecture of the system.
The deployment influence
Certain aspects of the architecture are strongly influenced by the targeted deployment
implementation platform of Java, WebSphere, and EJB.
What? No entity beans?
From previous architectural prototypes, and call.connect Release 1, and the current level of
EJB support within WebSphere, Geac chose not to use EJB entity beans for database
access. This was primarily on the grounds of performance, which was found to be significantly
slower than the equivalent hand-crafted Java Database Connectivity (JDBC) database
access.
There were also concerns over issues to do with legacy integration, specifically RPG
programs potentially accessing the same tables as those mapped by an entity bean. This was
an indication that there could be further performance problems.
Geac intends to re-evaluate the use of entity beans for the next release of call.connect. The
main benefits are of improved productivity and maintainability.
Session beans
The EJBs that contain the call.connect and vendor.connect Business Logic are designed and
deployed as
stateless session beans. This means that they do not (directly) maintain any state
specific data (for example, Order Number) across method calls.
In theory (and proven in practice by using the WebSphere Performance Monitor), this allows
the EJB container (WebSphere) to pool session beans, thereby reducing the resource usage
on the system. Even if there are 75 telesales operators all entering orders into the system,
there may be only 10 instances of the Sales Order Session Bean actively running (and
consuming system resources) on the system.
2.5 Reusing and extending System21 business logic
This section details the options that are available when considering how to maximize the
reuse of existing legacy application logic.
2.5.1 Accessing System21 RPG business logic
The need to reuse existing System21 logic was identified early on in the original call.connect
project. The following technical options were available.
IBM Toolbox for Java (previously AS/400 Toolbox for Java)
This is an obvious candidate. This has many classes for accessing iSeries objects including
calling programs.
