Starting from December 22nd 2009 is available the new version of TevereFlow.
Tevere Flow is a light-weight Workflow engine built using the Java® technology. Just download it and create your process using the Web interface. You can use Tevere as embedded or as external engine by using the provided Web Services API.
Tevere was built using Roma Framework under the Romulus consortium an it's currently used in several production systems.
Main features:
Open Source Apache 2.0 license
Web User Interface using the Ajax technology
Stand-alone application: just download and start it
Fully Transactional supporting any RDBMS or db4o ODBMS
Set of built-in commands available (email, web service invocation, etc.)
Auto-resume of failure activities
User and profile management
Activities can be written in Java or using any supported scripting language such as Javascript and Ruby
Integration via Java APIs or WebService
lunedì 14 dicembre 2009
Online a new demo of an application developed with Roma Meta Framework: Whiz! Whiz is the smaller Social Network never built. You can try it online or download it in local and change the sources as you want.
The Romulus consortium is organizing a new FREE event on December, 17th 2009: "Romulus FREE workshop: the new way to build Web Applications". The event is hosted in Rome, Italy under the form of a technical workshop. Most of the talks will be in the Italian language. If you're interested to have the same workshop in your city please contact romaframework -at- assetdata.it.
9.30 - 9.45: Presentation of the Romulus consortium [Talk in italian]
9.45 - 10.45: Introduction to Roma Meta Framework [Talk in italian]
10.45 - 11.00: Coffe break
11.00 - 13.00: Hands-on session: creation of a Twitter-like application from ground using the DDD approach and Roma Meta Framework. In this session the Asset Data's guys will help the attendees on installation and/or compilation problems. All the attendees with a notebook can download and install all the necessary to begin with Roma and follow the speaker step-by-step [Talk in italian]
13.00 - 13.45: Lunch with sandwich
13.45 - 14.15: Create automatic testing for the application [Talk in english by Universidad Politécnica de Madrid?]
14.15 - 15.00: Mashup of Social network's data with Google Maps and Flickr [Talk in english by Gesfor company?]
15.00 - 15.30: Exporting data in Semantic format (Semantic Web). Make the information accessible from a semantic search engine to execute queries like: "give me all the people living in Rome with at least 3 friends living outside his city" [Talk in english by Digital Enterprise Research Institute of Ireland]
15.30 - 15.45: Coffe break
15.45 - 16.15: Exporting of services and its usage inside a ESB (Atom and Web Services?) [Talk in italian by Imola Informatica]
16.15 - 16.45: Vertical demonstrators [Talk in english]
The Hook Aspect aims to write listeners of POJO events in simple way. The Hook Aspect allows the developer to extend an existent application in a flash. The Hook Aspect is based on the well known principles of Aspect Oriented Programming, AOP by now. The AOP supports the Object oriented paradigm. The two approaches can be used together to get the best of both.
You can hook any action of any POJO at runtime as well as read/write of any fields.
Using the Hook Aspect you can change and customize your application behaviour in a non-invasive mode.
Scope
Each hook belong to a scope. Scope can be:
SESSION, means that all the registered POJOs that are part of the current User Session will be waked up when the event is raised
APPLICATION, means that the POJOs are components declared into the IoC container (Spring IoC).
Using the scope APPLICATION you must assure that the POJO loaded by Spring IoC use the annotation @CoreClass(loading=EARLY) on top of the class declaration (look at the example below). This is the only way to assure to activate the Roma configuration when the application starts.
Below a table of the hooks available for the action:
@HookAction
Description
onBeforeAction
Invoked just before an action is called
onAroundAction
Invoked in place of the original action
onAfterAction
Invoked just after an action is called
onBeforeFieldRead
Invoked just before a field is read
onAroundFieldRead
Invoked in place of the original read. The action must return the value to return in place of the original
onAfterFieldRead
Invoked just after a field is read
onBeforeFieldWrite
Invoked just before a field is written
onAroundFieldWrite
Invoked in place of the original write. The action must return the value to assign to the field in place of the original
onAfterFieldWrite
Invoked just after a field is written
@HookField
Description
field
Copy the content of the field hooked everytime changes
Change the behaviour at run-time
In this example you need to avoid further login into the application for a while. The classic path would be to change the code or to write a parameter to switch on/off this feature.
Using a hook makes all things much easyer. Please note that the hook hookAroundAction means in-place-of. This action will be called in place of the original one.
ApplicationControl Example
@CoreClass(loading = LOADING_MODE.EARLY)
publicclass ApplicationControl {
@HookAction(hookAroundAction="CustomLogin.login", scope=HookScope.APPLICATION)
publicvoid hook() {
// DISABLE THE LOGIN System.out.println("Application in mantainance: login disabled");
RomaFrontend.flow().forward(
new MessageOk("login", "Login temporary disabled").
setMessage("Login is temporary disabled, please try in few minutes"),
"screen:popup:alert");
}
}
In the same way you can customize strategies, alghoritms, navigation paths all by using the Hook Aspect.
Collect results
This is an example of a simple profiler that record in a Map in memory the times the actions are called.
Remember that to use the scope “application” you need to instantiate the component as singleton by the IoC container (Spring IoC at this time). Add this line at the end of applicationContext.xml file of your application:
protected HashMap<String, Long> totalTimes = new HashMap<String, Long>();
@HookAction(hookAfterAction = "*", scope = HookScope.APPLICATION)
publicvoid profileAllActions() {
Long times = totalTimes.get("allActions");
if (times == null)
times = new Long(0);
times = times + 1;
totalTimes.put("allActions", times);
}
@HookAction(hookAfterAction = "*Login*", scope = HookScope.APPLICATION)
publicvoid profileAllLoginActions() {
Long times = totalTimes.get("loginActions");
if (times == null)
times = new Long(0);
times = times + 1;
totalTimes.put("loginActions", times);
}
}
Roma Framework is strictly based on the POJO Java architecture. Anything is a POJO from the view to the persistence. But in some circumstances it could be better having a lighter way to hide some fields in a form or adding a new action to an existent POJO.
This is the reason because Roma (starting from version 2.0.3) supports the Virtual Objects. Virtual Objects are treated just as real Java Objects but they are declared using a descriptor. Now only XML descriptor is supported but in future it could be planned JSON or other ways.
Virtual Objects, in effects, are declared using the same XML Annotation syntax with minor additions to handle field types, inheritance and other stuff that Roma can't know since the XML descriptor is not backed by a real class file.
Cross language
Virtual object's business logic is written inside the tag using the Scripting Aspect. This means that Virtual Objects are totally decoupled by the Java technology and they can be written in any language supported by the JSR 223.
Hot changes high productivity
Virtual Objects are loaded at run-time and reloaded every time the file is saved. This boost up the productivity since it never requires to restart the JVM!
Indeed changing the signature of a class (add and remove attributes and methods) require always the JVM to restart. This is the reason why the Virtual Objects are strongly suggested to being used to build forms to display.
Web IDE
It's planned for the end of 2009 a powerful graphic editor on the Web to change the virtual objects directly from the running application without the need of an IDE.
Not Just Forms
Even though Virtual Objects makes the difference used in the View Aspect, they can be improve the productivity in any Aspect of Roma. Think for example to a service written entirely in Javascript just creating the XML descriptor and annotating it with the Service Aspect.
Below an example of a Virtual Object that extends the Roma's CustomLogin standard POJO used to make the login. Note that by default the language setted is the Scripting Aspect is JavaScript but you can use any language installed using the JSR 223 implementations.
In this example the Virtual Object called “MyLogin” makes the following changes to the class CustomLogin that extends:
Add a new field called “help” defined as a String and displayed as HTML on top of all fields (see area definition)
Add a new field called “additionalCode” defined as a String. This field define some validation rules: it's mandatory and the length must be of 5 characters
In the constructor (see the scripting declaration inside the class) the field help is initialized with a welcome message.
The login action is overridden to check if the virtual field “additionalCode” is equals to “12345”. Only in this case calls the super.login(). Not the use of “me.parent” that returns the super class.
Add a new action called “close” to close the form. Note the use of “me.pojo” to return the real POJO in Roma.
Add a new action called “Standard Login” that show the classic Login form.
You can use a Virtual Object such as normal POJO in Roma. To display the Virtual Object just created write:
Documented the new feature about rendering images: now the type can be a java.net.URL to display remote images or images located in the filesystem outside the project
Component Aspect: now the IoC is managed by this aspect. Spring impl comes as in bundle.
New AspectManager to retrieve the right aspect impl + use of cache to speedup the lookup
Support for multiple aspect implementations that can exist in parallel
First step to VirtualObjects: refactored all the schema package and created the Reflection implementation
Improved speed on first class discovering
New Roma class as entry point for the most common user's functions
First step to remove Apache XmlBeans to load Roma XML files
Support for field's events
Removed the need of BackObject using FlowAspect.back()
Moved location of Spring files. From WEB-INF to src/META-INF/component
Removed manual inclusion of Spring files. Now are red all the files under the src/META-INF/component folder
VALIDATION aspect:
Separated from ViewAspect
Let to validate any POJO, also not rendered as form
SERIALIZATION aspect:
Implemented the new SerializationAspect to marshall/unmarshall objects in different formats (now only JSON and Java binary) and different strategies also pluggable
FRONTEND module:
New RomaFrontend class as entry point for the most common user's functions regarding the frontend (view, session, etc.)
The new Servlet filter "RomaWebFilter" starts and stops Roma
New SearchEngine module to build complex queries using a GUI
New GUI wrappers to handle collections as Select
CXF SERVICE module:
Support to JSON and JSONP protocols
Updated to use the last version of CXF: 2.1.3
JANICULUM module:
First version of Janiculum, the alternative to Echo2 View Aspect impl.
REST Access
Rendering impls are developed using FreeMarker to make easy to extend the framework with new renderers
REPORTING-JASPER module:
Upgrade to the last official version
ECHO2 module:
Resolved bugs for components inside a TableEdit rendered component
ADMIN module:
Fixed management of Base Groups and Base Profiles
USERS module:
Assigned primary keys to persistent classes
Login by default let the user to select the language between those installed in the application
WIZARDS:
Changed the syntax of wizards
Launch of module-install.xml ant file on module installation
Modules PERSISTENCE-JPOX, PERSISTENCE-JDO and WORKFLOW-POJO are removed from the official distribution. MAP aspect is renamed in GEO aspect.
Created CollectionWrapper domain classes to display collections in better way. Now there are two impl: TableWrapper<> and MasterDetailWrapper<>. See the Handbook.pdf to know more.
Disable the class checking for hot-updates. Useful in production
New refresh of multiple fields in one shot or the entire object
Resolved bug on the session management under WebLogic AppServer
VIEW module:
New "URL" rendering mode to embed static and dynamic content in forms. Now you can embed HTML files, JSP files and Web sites at all
Managed render of collections and arrays using the "OBJECTEMBEDDED" mode
Resolved a bug on table ordering
Improved Echo2 Table component in order to support the change of the color of the column headers
Updated to the stable version 2.1.0 of Echo2
DATANUCLEUS module:
Updated to the stable version 1.1.0 of DataNucleus
ADMIN module:
Fixed management of Info and InfoCategory instances
Created CRUD of GenericValue
JETTY module:
Integrated new release of Jetty 6.1.5
The script under the user project script/start-jetty.sh (and .bat) now works
CRUD wizard module:
CRUD now generate also: factory class (DDD), repository class (DDD), entry in package.jdo file if any