Common Use Cases
Apache Isis is great for rapid prototyping, because all you need to write in order to get an application up-and-running is the domain model objects.
By focusing just on the domain, you’ll also find that you start to develop a ubiquitous language - a set of terms and concepts that the entire team (business and technologists alike) have a shared understanding.
If you wish, you could combine this with BDD - the framework integrates with Cucumber.
Once you’ve sketched out your domain model, you can then either start-over and deploy with one of the deployment options listed below.
One of the original motivations for Apache Isis was to be able automatically generate a user interface for a domain object model. The framework’s architecture allows for different user interface technologies. The principal implementation is the Web UI (Wicket viewer), which as well as providing an appealing default user interface also has the ability to be customized the user interface by writing new Apache Wicket components. The framework provides a number of these.
Deploying on Apache Isis means that the framework also manages object persistence. Again this is pluggable. There are two implementations, either JDO (DataNucleus) or JPA (EclipseLink). These are normally used with an RDBMS, though in principle could be used with NoSQL databases. JDO/DataNucleus historically has extensive support for NoSQL, though JPA/EclipseLink also has some support also.
If the Web UI (Wicket viewer)'s extensions are too restrictive, another option is to deploy custom controllers/views for specific use cases alongside the generic viewer. This way you can use the generic viewer to deliver the majority of the app’s functionality, but you can justify the additional effort of writing a custom controller for those specialised/high volume use cases where a different flow is needed.
Because Apache Isis runs on top of Spring Boot, you can easily integrate any of the UI technologies supported by Spring, or of course use Apache Wicket for a similar look-n-feel.
REST (Representation State Transfer) is an architectural style for building highly scalable distributed systems, using the same principles as the World Wide Web. Many commercial web APIs (twitter, facebook, Amazon) are implemented as either pure REST APIs or some approximation therein.
The Restful Objects specification defines a means by which a domain object model can be exposed as RESTful resources using JSON representations over HTTP.
Apache Isis' RestfulObjects viewer is an implementation of that spec, making any Apache Isis domain object automatically available via REST. The set of domain objects can also be optionally restricted to exclude domain entities (thereby avoiding leaking implementation details).
There are three main use cases for deploying Apache Isis as a RESTful web service are:
to allow a custom UI to be built against the RESTful API
to enable integration between systems
REST is designed to be machine-readable, and so is an excellent choice for synchronous data interchange scenarios.
The framework provides SPIs to allow custom repreentations to be returned as required.
as the basis for a generic UI.
Another framework that implements the RO spec is the Naked Objects Framework (on .NET). It provides a complete generic UI tested against its own RO implementation.
As for the human-usable generic UI discussed above, the framework manages object persistence, for example using the JDO/DataNucleus objectstore. It is perfectly possible to deploy the RESTful API alongside an auto-generated webapp; both work from the same domain object model.
You may be happy to use Apache Isis for prototyping, but have your own proprietary application framework to actually build production apps.
Apache Isis supports this, because the programming model defined by Apache Isis deliberately minimizes the dependencies on the rest of the framework.
In fact, the only hard dependency that the domain model classes have on Apache Isis is through the
org.apache.isis.applib classes, mostly to pick up annotations such as @Action and @Property.
It’s therefore relatively easy to take a domain object prototyped and/or tested using Apache Isis, but to deploy on some other framework’s runtime.
If you are interested in taking this approach, then you will need to provide your own implementations of any framework-provided services used by your code.
If your own application framework is based on Spring Boot and with JPA or JDO, then there is another option. As noted above, Apache Isis itself runs on top of Spring Boot. You could therefore develop a complete custom UI using one of the regular Spring technologies and run that alongside Apache Isis - in effect the option described earlier but for every use case, not just selected ones. Apache Isis continues to manage the object lifecycle and persistence as a thin layer on top of Spring, but your custom UI renders the domain objects exactly as you require.