MetaBoss Beginner's Guide

Hello and welcome to MetaBoss Beginner's Guide! This place is for people who have not had any exposure to MetaBoss and would like to get a quick feel about MetaBoss, what is it used for and how does it help to develop software. If you have already built one or more applications with MetaBoss - this place is most probably too simple for you and there is a little point to waste any more of your time reading this section. If, however, you have not had any exposure to MetaBoss before, the answer to the questions "Is MetaBoss of any use to you?" and "Should you read any further?" depends who are you and what are you after. All we can do is to help you with the following executive summary:

The MetaBoss's value proposition is to "increase the return on investment in software development by directing most of the intellectual effort towards modelling the business domain in a technology neutral modelling language and use automation to produce real world systems". Generally speaking MetaBoss helps to build high quality distributed computer systems which:

• Can be deployed on many different computing platforms without redevelopment.
• Can scale up and down (again without redevelopment) in sync with business requirements and operating budgets.
• Relatively easy to refactor and meet additional requirements.

Well, here you have it. It is now up to you to decide whether MetaBoss may be of interest to you and whether you wish to give this guide a chance.

Index

What we expect you to know?

This guide is targeting beginners in MetaBoss, but not beginners in Information Technology. Therefore we expect you to have some level of understanding in following areas of computing:

• SDLC - especially design, code, test phases.
• UML modelling, especially class and statechart diagrams.
• Service Oriented Architecture concepts.
• Domain Data Objects, Relational databases and Object / Relational mapping techniques and issues.
• Java language.
• XML language.
• Apache Ant driven build process.

If you are not familiar with majority of the listed topics, you may find this example somewhat challenging and difficult to understand.

What does this guide cover?

In this guide we will show you how to design, build and test your first MetaBoss system - simple (and often used in similar examples) University Course Registration System. The aim of this guide is to take you through all the steps as fast as possible, therefore the system is simplified a lot.

At the end of this guide you will have:

• UML model of the University Course Registration System. It will have services model and domain object model
• Ant script used to build various artefacts from the model.
• Database creation script (Oracle or MySQL are your only two choices at the moment).
• Full middleware code (everything from Service tier down to database). The code is enterprise technology independent and is deployable over CORBA, J2EE, RMI or even without any remoting mechanism as part of the "fat" client.
• A number of executable test cases expressed in XML. These test cases used to populate the deployed system with the test data and test various usage scenarios.

The end result of working through this guide is provided with MetaBoss release in the ${metaboss_home}/examples/AmlaMater folder. Please note that MetaBoss release also contains more complex example of HatMaker enterprise, but one has to learn how to walk before learning how to fly...

What will you need?

You may choose to passively read this guide (i.e. read the guide, look at example files but do not attempt to repeat the actions described in the guide). In this case you do not really need anything apart from this guide (and it appears that you are reading this, so you are 100% equipped to proceed).

University Course Registration System Description

The University Course Registration System we need to build helps to maintain information about Students, Teachers and Courses. Courses are attended by Students and have Supervisor and Lecturers (both are Teachers). The system must offer basic services for creating, deleting, updating of Students, Teachers and Courses as well as provide specialised search and reporting services such as:

• Find all free Teachers (ie. the Teachers who are not assigned to any Course). In other words find all Teachers who are not listed as Supervisor or Lecturer for any Course.
• Find all Teachers who may be familiar with the particular Student. In other words find all Teachers associated with any Course attended by particular Student.

Modelling the system

Preparing and running the Ant build file

After we have finished modelling, the next step is to generate, compile and package various model-driven documents such as Java source, Database creation scripts, System test scripts etc. We will do that using Apache Ant build tool in conjunction with a set of MetaBoss's customised Ant tasks. Ant build process is driven from the build file which contains definition of the sequence of build steps in xml format. The build file is located in the ${metaboss_home}/examples/AmlaMater folder.

Review what we have built

At the end of the successful build your console should look something like the one below:

In this chapter we will explore the artefacts created during the build. So, if you do not have much time and prefer to run quickly through the example, you may skip this entire chapter.

Two new directories 'Release' and 'Build' should now appear under your ${metaboss_home}/examples/AlmaMater project directory. The Release subdirectory contains all releasable parts of the build. The idea is that one can just create archive out of this subdirectory and release it to consumers. The Build subdirectory contains all temporary files produced during the build. Most interesting files her are the the source files generated by MetaBoss. They are located in the Build/generatedsource subdirectory.

Adding handcoded service implementations

At this point in our example we already have a large portion of code generated for us from the model. As we have seen in the previous chapter, we already have interfaces for all business services and implementations for the domain support services which offer trivial Create/Read/Upate/Delete operations for all entities. So what is left for us to handcode? The only thing left is the implementations for the special services we have modelled ourselves. These services are non-trivial and the model does not have enough information for MetaBoss to generate implementations automatically. This is because MetaBoss (similarly to any other tool we know) does not support the moment modelling of operation implementation. The reason is that the problem domain is too complex and the range of possibilities is too wide (In fact it may well be that there is no language higher than programming language itself, which is able to fully describe operation implementation).

Deploying the system

There are many ways to deploy the system built with MetaBoss. The simplest way is to pack all generated jar files together with a small number of required framework files (eg. tyrex.jar for transaction management, log4j.jar for logging, mysql-connector.jar for database access etc) into the single deployment unit and deploy it at the "fat" client end. In this single JVM mode(or as we call it "inprocess" mode) there is only one client application JVM (eg. Swing GUI application or Struts Web application) and middleware is not remoted. The reason this way is simplest is that there is only one JVM to worry about, so creathing right classpath, deploying and debugging is easier.

However, large enterprises do not usually work this way. Small benefits of inprocess middleware deployment qickly become liabilities when large organizations have to deal with change management and multiple client interfaces (eg. Web apps, WAP apps, Web services, Desktop apps etc). Here is where distribution comes to the rescue. Distribution is the technique where systems are broken up to a number of pieces and deployed over a number of computers. MetaBoss's multilayered architecture contains two service layers: the Business Services layer and the Storage Services layer. Systems can be distributed at either or both of these boundaries. The choice of the distribution technology is also quite large. One could use RMI, CORBA, J2EE or any other remoting mechanism (if MetaBoss does not have required generator - it is normally quite simple task to create one). In order to deploy the system in distributed fashion one needs to generate distribution proxy for the chosen service layer (Business or Storage) and for the technology of choice. After this is done, the client and server JVMs are configurred to work with each other using JNDI componentisation mechanism.

We actually consider distributed deployment to be an advanced topic and for the purpose of this beginner example will not delve into it any further (please refer to the HatMaker example for more on this subject). What we will do is demonstrate simple inprocess deployment. We will combine this with testing in the next chapter. The whole system will be deployed in one unit (ie. single JVM) together with the Test Scenario Runner application.

Testing the system

Once the system is deployed - it is time to test it. The outcome we want to achieve in this step is to verify that the system is working correctly and possibly create a regression test artefact to help us ensure that there is no regression in future releases. To test our system we will use MetaBoss Testing Framework.

We have only coded a portion of the system - the one which implements special queries - and we will mostly concentrate on testing this very portion. This is because statistically the code generated by MetaBoss has far less problems than the one prepared by hand. Having said that, the testing requires to create database and populate it with known dataset. To do that we will use generated database scripts and some of the automatically generated operations, so they will be tested any way. Broadly speaking, the testing involves following steps:

• Design the test cases including the dataset they are to be executed with. The overriding goal of the design is to allow us to test as much as possible of the functionality. This involves understanding the operations being tested, planning what conditions should be tested, listing all the required operations inputs, expected outputs as well as entities together with their attribute values and relationships. The dataset definition and test cases are stored in XML format in accordance with the schema generated from the model - this ensures that the sample data and the operations used in the test cases are aligned with the model.

• Create the database and populate it with the dataset which we have designed in the previous step. To create the database we use database creation SQL scripts generated from the model. To populate database we use the database maintenance test scenario scripts, which in turn use actual DomainSupport services generated from the model (ie. they are not SQL scripts, they are database independent test scripts expressed in XML).

• Execute the test cases and study the results. If results are matching what was expected - excellent. If not we would need to find what went wrong: The problem might be in our test cases or coding or even design. This is where the process becomes iterative. We will have to go back to whereever the problem is, fix it and re-run the build and/or test process.

• At the point where we are happy with the test outcome, we may save the test result file for future use in the regression testing.

The centrepiece of the MetaBoss testing framework is the ScenarioRunner utility. This utility reads test case definitions, executes them by invoking enterprise services, records the results and possibly even compares them with trusted specimen results. ScenarioRunner is integrated with Apache Ant which allows to program complex test procedures and combine various preparation steps (eg. database initialisations) with test scenario runs.

Conclusion

This example has shown how to use various parts of MetaBoss tool set to design, build and test simple enterprise system. We hope that you have enjoyed working through this example with us and that you have seen enough to make a decision whether MetaBoss is right tool for you. Just to increase your appetite a bit more, we would like to list the advanced MetaBoss features which were deliberately left out of this example in order to keep it simple:

• Comprehensive data types modelling facility

  This example has only scratched the surface of the MetaBoss's business data types framework. It is possible to define any imaginable data type in the model. For example the data type specification may include regular expressions to validate the values against. It can also list the limited set of enumerable values (eg. days of the week).

• Object Constraints facility

  This example has not demonstrated the ability to specify validity constraints on Operation Inputs, Data Structures and Entities. Constraints are very important part of the system design. They are specified in the model at the design time using OCL (stands for Object Constraints Language. OCL is specified in the UML specification). Based on these constraints in the model MetaBoss generates data validation code which ensures at run-time that constraints are not violated.

• Entity collection filtering facility

  This example has not demonstrated the ability to model any number of Entity Selectors (ie. filters) which then become selection methods on the Java classes which represent the collection of entities. Selectors are very powerful igredient of the MetaBoss domain entity collections mechanism.

• Entity state machine facility

  This example has not demonstrated the ability to model Entity State Machines using UML State Machine diagram (for example Student entity might have 'Applicant','Current' and 'Graduate' states with appropriate transitions between them). If Entity has a State Machine associated with it, the generated code will automatically ensure that the value of the State atribute can only be transitioned in the directions specified in the State Machine diagram.

• Ability to deploy the same system on a range of technologies

  This example has not demonstrated that the same binary, without any changes or even recompilation, can be deployed in CORBA or J2EE environment. This is achieved by building and deploying additional distribution proxy layer for the chosen technology (building is fully automated step and deploying done usig JNDI configuration file).

• Ability to automate the test acceptance process

  This example has not demonstrated that the Test Cases can contain acceptance conditions which are automatically verified by the MetaBoss Testing Framework during testing.

• Ability to automatically build Web Services layer

  This example has not demonstrated that MetaBoss allows to expose all or some services as Web Services, without any changes or even recompilation to the system code. This is achieved by building and deploying Web Service front end layer. The build of this layer is fully automated and resulting Web Application Archive can be deployed straight into the servlet container (eg. Apache Tomcat).