Public Beta of Play! is Now Available on Heroku
Heroku announced yesterday that Play!, a Java Web Framework was now available as a public beta. Play! has taken a "clean room" approach to Web development and decided to not be bound to various self-imposed restrictions such as :
compatibility with servlet containers, support for JSP, compatibility with the standard Java web app layout, and conformance to Java and OO principles even when they don't make sense.
As such, Play! follows the "Built-and-Deploy" model of Ruby on Rails, instead of the more traditional "Package-and-Distribute" model.
No boilerplate classes or XML config files are needed. The framework takes a fresh approach to packaging conventions, and uses static code where it makes sense. For example, since controller entry points are stateless, and HTTP-oriented instead of object-oriented, they are implemented as static methods.
Just like "Heroku for Java" which was just released last week, Play! is based on a containerless PaaS model. A Play! app can run locally or seamlessly be deployed in production. This results in a simplified deployment workflow and eliminating any problems caused by environment differences.
From an architecture pespective, Play! uses Netty, a non-blocking I/O protocol library built by the JBoss team which supports the asynchronous processing of requests using a continuation based programming model. Play! is also implementing a share-nothing model which makes it easy to scale out applications horizontally by adding more nodes since stateful sessions are not possible.
From a Language strategy perspective, Heroku explains:
Java is another milestone on the polyglot platform path, but there's more to come. Future language packs will span the gamut from venerable (like Java) to cutting-edge (like Clojure and Node.js) to squarely in-between (like Ruby). Our desire is to be as inclusive as possible. Choice of language is up to the developer.
Are both the Web App and Java spaces ripe for disruptive innovation by cloud application platforms as Heroku suggests? What's your take on it?
My take on PaaS
The last thing we need at the moment is a black box container for the edge execution node that restricts the service world to that of a particular PaaS vendor, service provider, technology, runtime or language. Lets create much more compatibility, coordination and robustness in the infrastructure and services making the edge nodes (devices or containers) as unrestricted and diverse as possible until we have gained a greater understanding and appreciation of the cloud and its possibilities which could very well invalidate our current application architecture and deployment approaches (i.e. webapps / containers) today.
Re: My take on PaaS
I don't necessarily disagree with your point of view, but:
a) don't you think PaaS reflects an optimization of many people building the same thing on top of IaaS. You lose control, but you gain in LOE and Robustness. Configuring a set of servers, elastically, at the IaaS level is no simple task
b) When you say "I believe so strongly in the separation & control of this differentiation that I expect all services to allow delegation of some aspects of their execution & delivery." I wholeheartedly agree with you, but maybe we disagree on how that could be achieved. I personally don't believe this is a good idea to achieve it dynamically. I would rather prefer an "assembly" mechanism like the one of SCA which allow a single service (component) to participate in different assemblies and hence allow this level of delegation, but statically defined for every "consumer" of the service component
Re: My take on PaaS
I think it is much harder to configure servers that execute code you did not design and develop which is why I advocate for this to be pushed out to other service providers. Today It's not just about building software and having your customers learn how to administrate and manage it. You need to be able to operate it as well at a scale much greater than a signal customer.
You need dynamic delegation at the service interface (context/contract) level because I should be able to interact with a service and ensure it places the data I create (directly or indirectly) in a storage location that is under my control beyond the service its self otherwise there is a lock-in situation and a risk factor (if the supplier goes out of business/service). Migration then becomes easier but not easy and more importantly the cost of access to such data is outside of the control of the service and in the hands of the storage service ensuring pricing is not used to restrict exits. In addition I expect brokers or other mashup like services to augment but still pass thru requests which does require a service to have this delegation on a per user basis but which looks to the other services in the supply chain as on a per request basis because they don't see the user itself because its not part of their domain.
Every time your purchase something on the web you always have the option to change the deliver address and billing address though by default it assumes your home address but there are times when I am buying for different people under a different context (cost center). Do you not think the virtual world will have some similar mechanisms that have been proven to work much longer than its own creation? We need to design and developer software like it was engineering a business and its systems, models, events/signals, processes,....
Re: My take on PaaS
OpenCore 6.3UM – Everywhere Usage Metering
Play looks nice, but they have not done much research.
Mojasef (originally released back in 2005, and still being developed) takes a similar, but potentially even simpler, approach, and there are several others if you look around the web a bit.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015