Principles
The XOo°F architecture is based on a classical 3-tiered decomposition. This decomposition ensures that it separates completely the presentation/user dialog layer from the business logic layer. The core logic of the application can then be accessed from different client applications or presentation engines.
The client applications can be everything going from a GUI to a B2C or B2B website, EAI applications or even a testsuite.
The business logic is decomposed into a facade, exposing the business logic as services, and the core domain model that is only accessible through the façade.
Figure: Typical 3-tier application blueprint
However, adopting a multi-tiered architecture is not the only key to success: Issues like openness, simplicity, documentation of the systems interface, performance, etc have to be addressed in order to build robust, flexible and easy to maintain systems.
XOo°F is based on an industry standards approach (UML, XML, COM+, J2EE, .NET, etc.) and embodies the current best practices in software development. The framework is lightweight: it embraces the best of current technology and pickup where it stops.
Best Practices
The XOo°F framework embodies the following best practices:
XML Messages
Formal specification
State-transition diagrams
Stateless application server
XML Messages
The business logic is accessed using XML messages. The usage of XML for representing the messages addressed to the business logic ensures:
openness: the system is not locked in a specific platform, middleware of programming language,
simplicity: XML is simple,
loose coupling between the business logic and front-ends (ex: Web presentation layer, GUI, ...),
scalability: because of the flexibility of XML, it is possible to extend the message without breaking the compatibility between the various clients and the business logic. The XML message can be interpreted loosely.
However, our solution is not to be confounded with Web services: it is not especially tied to HTTP as a protocol for message exchange. Depending of your technical standards the business logic can be exposed as COM+ components, EJB components, CORBA components or as a Web service.
The XOo°F framework provides a custom XML schema language to specify the structure of the message: XMLStruct. Code is generated for various programming languages: VB, Java, Python, C#. The generated code can validate the messages using the constraints expressed in the specifications. Such kind of constraints is typically defined during analysis phases, found in documentation and re-expressed in code (pre/post-conditions). Automatically generating constraints from the XML specifications helps preventing inconsistency between the code and the documentation.
Moreover, a complete HTML/PDF/RTF documentation can also be generated to document the messages.
A DTD specification and/or an XML schema definition are also generated for each message specification.
Figure: XML Messaging made easy
XMLStruct is an XML language to specify data structures, ie declare all fields that can be present in the data structure
A particular instance of such a data structure can also be represented in XML format; it is also called a message
Formal specification
The formal specification describes the service facade of the business logic from a reasonable granularity. In order to ensure consistency between specification and implementation, code is generated from the formal specification.
This formal specification can also include a multilingual documentation of the service facade. By integrating the formal specification and the documentation, the overall quality of the documentation is improved. The documentation is available in HTML form or in PDF/RTF.
The XOo°F framework provides a custom XML language to describe the service facade: XMLClass. XMLClass is an XML language to specify an application server's interface. The specification language is:
Object Oriented: it supports Classes, Class methods (which corresponds to services), and Instance methods (which corresponds to actions on business objects),
Message Oriented: it uses the datastructures defined by XMLStruct as input and output parameters,
Technology independent: from the formal specification code is generated for various platforms like COM+, EJB, Servlet, Python and .NET.
The XML specification makes it also possible to define constraints on the messages exchanged between the server and the clients like mandatory arguments, value ranges (e.g. must be positive, within a range, in ['M','F'], ...). In cases where specifications are not used, this is most of the time expressed in the documentation or in source code comments and re-expressed in code (via pre- and postconditions). This is a major source of between the code and the documentation. By using XML specifications, those constraints are only expressed once in the specification. Generation of code and documentation ensures the consistency between both.
State-transition diagrams
When designing the interface of a business object, often protocol information (the dynamic behaviour of objects) is not presented in the system documentation. The dynamic behaviour of objects is defined in interface specifications when the documentation indicates that some messages must be sent before others, or that there are conditions for a particular message to be acceptable by an object. At the implementation level, these restrictions are checked against a set of preconditions at the beginning of each method. State transition diagrams are a formal mechanism to express such constraints. Code is generated to enforce this dynamic behaviour when the system is running.
These state-transition diagrams are based on UML. However the solution goes further than most others by generating code and documentation from these specifications.
Stateless application server
Applications must face with horizontal and vertical scalability.
Horizontal scalability: increasing the number of machines hosting the same service;
Vertical scalability: increase memory and power of a same machine to run several instances of the same service.
Stateless components allow the multiplication of servers, enabling a good scalability of the system. The components can be activated on any machine. To allow this, some considerations have to be taken into account:
Users are not allowed to interact within a database transaction,
system resources are not tied to a particular client or user: any available database connection can be allocated to serve requests from any user.
Prioritisation of requests and load control as a result of asynchronous processing of long-running operations