MetaBoss Programming Model Guide.

System Layering.

Index

What is system layering ?

Typical computerised business has some sort of data storage, most typically database, holding all enterpise data. All systems for internal staff, for clients over the Web or partner interfacing systems are built around this data storage. All of these enterprise systems have parts of code dealing with storage operations, some parts of code dealing with business rules and some parts of code interfacing with end user or other systems.

MetaBoss generated system is split onto a number of layers with each one having well defined set of responsibilities, interfaces to other layers and certain layer visibility rules. Formal layering helps to disect, distribute (i.e. make systems run on more than one computer) and secure systems. Layering also helps to reduce ripple effect of changes to parts of the system.

Layers in MetaBoss generated system

MetaBoss system layers are shown on the diagram below

In more detail:

• Storage Layer.

  This layer is responsible for interfacing to the actual storage mechanism (database or flat file or whatever). Its interface to the outer layer consists of components with CRUD (Create Read Update Delete) operations for each and every business document kept in storage. This layer is stateless - it means that it does not "remember" the context of conversations and every operation it offers is fully self contained and atomic (i.e. operation inputs contain enough information to complete the operation). From the scalability point of view this layer can easily be "cut off" and deployed on separate hardware. At this layer it is also easy to run multiple copies of components and balance the load between them. In a scalable distributed system this layer should be deployed somewhere close to the database server, if not on the database server. From the security and access control point of view - no other layer has rights or ability to access data storage directly, so database connections can be firewalled off at this layer's boundary.

  Interface and implementation for this layer is fully generated by MetaBoss. Interfaces generation depends on modelled business entities and relationships between them. Implementation generation additionally depends on chosen storage technology. Customised implementation of the generated interfaces can be developed and plugged in if required.

• Domain Objects Layer.

  This layer is providing ability access enterprise data organised in domain objects hierarchy. Its interface to the outer layer consists of components representing business documents (not operations on documents like storage layer, but documents themselves). Each component has operations to read and modify attributes of the document and to navigate to associated documents. This layer is statefull - it means that it does maintain the context of conversation and domain navigation history. From the scalability point of view this layer is not a convenient "cut off" point and is best used as a facade and deployed as client side library "in process" of the outer layer. Implementation of this layer does all storage operations via Storage Layer.

  Interface and implementation for this layer is fully generated by MetaBoss. Generation depends on modelled business entities and relationships between them. Generated implementation of this layer does all storage operations via Storage Layer. Customised implementation of the generated interfaces can be developed and plugged in if required.

• Business Services Layer.

  This layer is responsible for business functions. Its interface to the outer layer consists of components with operations fulfilling each and every business function or possibly entire business process. This can be stateless or stateful (stateless is preferred and recommended). From the scalability point of view this layer (if modelled and developed as stateless) can easily be "cut off" and deployed on separate hardware. At this layer it is also should be easy to run multiple copies of components and balance the load between them (again if layer is modelled and developed as stateless). In a scalable distributed system this layer should be deployed somewhere close to client systems. From the security and access control point of view this layer can easily be firewalled off.

  Interface for this layer is fully generated by MetaBoss. Interface generation depends on modelled business operations, their inputs and outputs. Implementation for this layer is generally not generated. It is expected that implementation of the generated interfaces is developed and plugged in. Although implementation is only limited by Java language and is free to do anything (e.g. not even use inner layers or use storage layer directly), it is strongly recommended that implementation code uses Domain Objects Layer when accessing enterprise data.

• Client Adapters Layer.

  This layer is responsible for enabling execution of Business Service Layer operations from special technologies, which are unable to use Business Service Layer operations directly or would be greatly inconvenienced if asked to use Business Service Layer operations directly. Components at this layer are typically no more than wrapper classes, which "adapt" Business Service Layer operations to some other technology or fashion. For example DOMAdapter components allow to execute operations with inputs and outputs packaged as org.w3c.dom objects. Use of this layer is optional. Standard Java Swing or JSP clients will work fine with Business Service Layer directly

  It is important to remember that adapter component internally does conversion of operation inputs, calls Business Service Layer operations and returns converted output. Adapters are always invoked "in process" only by clients who need it. All conversions are taking place on client side, which has a number of advantages such as not overloading shared Business Service Layer by extra processing and independence of the shared Business Service Layer code and deployment from some additonal technology specific libraries.

  MetaBoss comes with a number of generators for various types of adapters. Choice of adapter generators included with MetaBoss is always increasing to include new technologies. If necessary specialised adapter generators can easily be created by project developers or us (we will be more than happy to help you with your specific needs).

• Client Systems Layer.

  This layer contains actual client facing applications. It might contain Java/Swing desktop applications, Java/JSP Web applications, Web Service servers, etc... At the moment MetaBoss does not provide modelling and generation facility for the client systems (It is in the pipeline though!). However, it is possible to build all kinds of Client Systems, using wide variety of technologies and connecting to middleware built with MetaBoss. For example, apart from obvious Java based technologies (Swing, JSP etc), we have helped to sucessfully develop and deploy Microsoft Visual Basic clients (with use of third party Java/Windows bridge) and ColdFusion web server applications.

Conclusion

Software generated by MetaBoss is split in a number of layers. Every type of layer has certain set of responsibilities and rules. Formal layering helps to reduce ripple effect of technology changes as well as scale and secure the enterprise sysetms.