Hi,
Now that v1.2 is out of the door, what should we work on for v1.3? Here
is a list of potential things. Most of the things here are based on my
experience from Streamflow, i.e. things that are really useful to have
in real projects.
First off, some things I want to backport from Streamflow into Qi4j:
* FileConfigurationService - service that determines where to put files
in a filesystem, based on platform defaults. With this service it
becomes much easier to know where application data, configuration and
logs should be placed
* JMX services - extract the current JMX helpers from the REST extension
into their own library. From Streamflow we also have a service that
exports configurable services into JMX so they can be easily edited
there (VERY useful!!!), and a JMX remote connector
* DataSources - service for instantiating and configuring DataSources
* LiquiBase - wrapper service for LiquiBase, to do RDBMS refactorings
* Eventstore - API and backend for storing events for EventSourcing.
Currently based on JDBM, which works, but is not optimal perhaps
* Solr query/indexing - Solr implementation of Query/Index SPI. This
gives you free-text searching in your domain model.
* REST/CQRS API - Based on Restlet, this makes it easy to construct full
REST API's (with HATEOAS) and also enables DCI as the application layer
in an app. Comes with client as well.
* Console - BeanShell console that can be exposed through Restlet. Handy
for debugging the domain model and administrative commands
* Probably some more things I can't think of right now
All in all, a nice set of features that would be useful in any real-life
project.
Then there are some things that we need but have not yet started:
* Circuit breaker library - for every external services (email,
database, LDAP, webservice) we want to use the circuit breaker pattern
(look it up). We need a simple library that can do this, and expose it
in JMX for management tools to monitor/configure/reset. This is crucial
to handle production issues, and track the health of an application.
* Active -> Available - currently it is possible to check if a service
in Qi4j is "active". In practice I've found that it's not really all
that useful, and what is instead needed is to check whether it is
"available", meaning, if I call it, will it respond? This goes hand in
hand with the circuit breaker library for external services, but for
internal services it is also useful since many of my services have an
"enabled" configuration property, which when false should be able to
tell service users that the service is unavailable at the moment.
Apart from the above, there's a couple of NOSQL datastores that we could
easily add support for (it seems). I looked at CouchDB the other day,
and it's datamodel seems like a perfect fit for us, so.. why not?
This is a start for what we could do. Much of it is already done in
Streamflow, so it's mainly a matter of porting it. It may need touching
up as we move it, so it is more standalone, but that should not be too
difficult. The goal with 1.3 would be to have more production features,
and also allow easy implementation of REST/CQRS/EventSourcing, which are
hot topics these days, and for good reasons.
WDYT?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
