a new way to conceive Web Applications

Continuing the notion of the agility on developing SOA enabled applications, I have stated the (b) Web API-ing post, relating the development of a web application and web services to the SOA ‘enableness’. In that (b) part of the agility, it was mentioned that after determining the need of an ESB ( in (A) ESB –ing ) and the requirements of the application, one should pay attention to the API development. After these general points of analysis and view, there is the ‘specific’ part, the part that the abilities and knowledge of the specific tools that the team uses. There is a wide range of frameworks and tools and therefore approaches for developing and architecting the ws nature. I tried to begin with the quick and dirty approaches for quick ws development related tools (and I'll continue, because there are some more –specific- tools to tell about, further to OpenEJB mentioned there. Stay tuned for ws serving next parts ;) ).  In order to be as much agile as possible, you need a more general approach.

From the architecture point of view, either in Web APIs or the interoperability and connectivity parts of the application under development, there is the web services part. The architecture should be able to address and solve (or conform to) various constrains of the existing environment of applications, or the external resources that should be used by the services. Having in mind that every day a new tool or framework appears on the market, using a technology means to have a binding with it, very often forever. What happens if you want to change the engine that persist your objects? Or again your web framework? Or in order to enrich some parts (very often a ‘second-day’ engineering or project from your customer for something you or someone else began in the past) of the whole application?

Problem. Sometimes  mind-troubling , you know, costly and with huge migration costs.

The answer, or something close to it is the … META framework.

The Roma framework allows you to develop enterprise level Java applications with low effort following a real Domain Driven Design approach. It's a new way to conceive the application: anything is a POJO, from the GUI forms to the persistent objects. Using the Meta-Framework approach you can integrate the latest breaking technology in your application without modifying your domain and application logic because they are really decoupled.

Roma is the only “meta” framework. Using Roma you're definitely free from the technology you're using. How it works? Roma provides very generic behaviour interfaces called “Aspects”. Aspects enclose the most common use cases. Using the tool and framework through the Aspect allow to leave your code clean from the technology.
But if there is a need to dirt hands using the technology directly, can this be done with Roma? Sure. You can always reach the implementation under the hood. Just remember you had to migrate that pieces of code in case tomorrow you'll change the technology. In the documentation you can find some best practice to make migration the easiest possible.

Abstracting the technologies let you to have the development team aware of their. This can be translated as minor skill requested, therefore less cost. That’s why Roma allows you to develop enterprise level Java applications with low effort following a real Domain Driven Design approach.

Example:

   1: @ViewClass( layout = "popup" )  

   2: public class EmployeeForm {  

   3:   @ViewField( layout = "expand" )  

   4:   private Employee entity;  

   5:     

   6:   public void save(){  

   7:     ObjectContext.getInstance().getComponent(PersistenceAspect).updateObject( entity );  

   8:   }  

   9:   

  10: }  

Using the Meta-Framework approach you can integrate the latest breaking technology in your application without modifying your domain and application logic because they are really decoupled.

The great thing is that Roma provides you automatic support for every layer and aspect for your application, from dynamic web user interface and persistence, to report functionalities, portlet development and semantic technologies. Here is a bird-eye view:

Roma is Open Source and licensed under the commercial friendly Apache 2.0.


There are some tools and frameworks supported today and you can see all of them there and stay in touch here for other tools that can be used into it, extending the outer circle of the above image ;) .

A quick example is to use the kernel of ServiceMix, as the ESB related functionalities. ServiceMix Kernel is a small container based on OSGi.  The latest release allows external clients to connect to it and issue commands using a simple protocol implemented on top of TCP or SSL.  However, this remote-ing protocol has some drawbacks as the internals makes it unable to do another remote login from a remote session.  In addition to that, completion and history do not really work great. A way is to use the SSH protocol, which is widely used, secured, with tons of different clients available. Unfortunately, no SSH server is available in Java.  There is a post for SSH Server in Java trying to do just that, based on the IEFT specifications, the JSch SSH client library, and the OpenSSH server source code.  The server itself is based on Apache Mina which is a great framework for using NIO. The project is available at http://code.google.com/p/sshd/ and although there are lots of limitations right now, the basics of the SSH protocol work. 
There is a plan to integrate it in a bit into ServiceMix Kernel as the default remoting protocol.  Maybe over time, we'll be able to implement SFTP or even a full SSH server integrated with Unix OS (I've already made some tests, but I'm missing a few bits on the PAM integration for authenticating against the OS).

So this might be a good chance to accommodate the ESB and ServiceMIX thoughts share from these posts and further more be a step closer to OSGi.