IBM SG24-6526-00 manual Architectural representation, Architectural goals and constraints

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

16Geac System21 commerce.connect: Implementation on the iSeries Server