16 Geac System21 commerce.connect: Implementation on the iSeries Server
e-mail requesting information. The e-mail reply is then used to control the next step in the
process. For example, in an order fulfilment process, if an order cannot be fully allocated, the
process can e-mail the customer and ask if a part shipment is acceptable. Links in the e-mail
send a yes or no response back to the process, which continues appropriately.
2.4 Architectural representation
The deployment requirements (for example, must be able to run on a single iSeries machine)
considerably affect the overall architecture in terms of physical location of database, code,
etc. However, Geac ensures that the architecture is not constrained by these physical
limitations.
There is a logical view of the architecture that identifies each significant layer of the system
and shows how that layer maps onto a design and implementation tiered architecture. For
example, Geac can deploy the Business Logic for vendor.connect onto either the iSeries
server or Windows 2000.
2.4.1 Architectural goals and constraints
In an ideal world, the architecture allows and assists the product team to build the ultimate
system with infinite flexibility, scalability, ease of use, and installation. In the real world, each
interested stakeholder has their priorities for the system.
For a sales person, the system should be seen as infinitely flexible and expandable. In reality,
meeting these aspirations may lead to an architecture that is overly complex and
cumbersome for the main day-to-day running of the system. Therefore the architecture is a
trade-off between many requirements.
2.4.2 Non-functional architectural considerations
This section details the key requirements of the system that may significantly impact the
architecture:
Compatibility with System21: The architecture needs to consider that all .connect
applications have a constraint that they must be compatible with System21.
Performance and scalability: The system must meet specific volume and response time
requirements for the project where the product will be deployed.
Re-usability: Both call.connect and vendor.connect were originally developed as part of
individual specific customer projects. The justification for the development of is that Geac
expects to have a significant amount of design and implementation re-use for future
projects. Therefore, the ability to re-use and extend the core business logic is vital to the
success of the product.
The follow on to re-usability is supportability: Geac must be able to enhance and add
functionality to the product while supporting existing installations from the common design
and code base.
e-commerce support: The call.connect EJB Business Logic components form the
back-end order entry system for the Geac e-commerce solution, web.connect. Therefore,
the architecture must support or be extendible to support the Web deployment model of
servlets, JavaServer Pages (JSPs), etc.
Deployability: In the short term, where possible, both call.connect and vendor.connect
should be deployable on a single iSeries running alongside System21 on the same
physical hardware. Due to hardware and system software constraints, it may be necessary
