isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GESCONSULTOR - Óscar Bou <>
Subject Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Date Sun, 08 Sep 2013 09:37:58 GMT

I must admit that was one of our expectations when we firstly approximated Isis, perhaps because
we were following the email list or saw the SQL Objectstore, etc.

In fact, seems that recently we have taken the opposite path (by requiring nearly all Entity
properties to be annotated with @Column(allowsTrue="true|false"), instead of improving the
JDO Object Store usage of the Isis meta-model.

It would also have another advantage: it would be the way to also support JPA implementations
(or lessen the effort required).

But we cannot expected to map/solve all ORM requirements on the Isis metamodel, so the end
situation will be some inferred, some explicited for sure.

I think that perhaps we must clarify Apache Isis responsibilities, and concentrate on them.

So let me do a "quick-and-dirty" Envisionning exercise (it's Sunday...).

Apache Isis intend to provide programmers with the best framework for implementing Domain-Driven
Applications that interact with its environment without compromising business logic.

For that, I would say (for debating) the following (quick) responsibilities:
- The core responsibilities are:
1. to ease on Domain implementation (Entities, their relationships, and behavior / business
rules / actions). 
2. to ease on Domain interaction with the environment (establishing ways to securely "share"
that Domain Rules with the environment - applications or humans -).
3. to ease on Business Logic "protection" against "business-logic thieves such as UIs and
ORMs" (by having all "contextual" info needed for the domain, and also for the actors interacting
with the Domain).

From such a perspective:
a. From the ORM framework, we only need on the meta-model those annotations that affects the
behavior of the Domain (read-only / transient, required, etc.) or the way the actors interact
with it ("memo/blob" fields, etc.). But we don't need any information regarding how the ORM
framework will store the domain, for example (any related to inheritance mappings, table or
field names, etc.).

b. From Bean Validation frameworks, in theory we need "all"... It's all related to Domain's
behavior. But we can simply consider it as "another idiom" to express Domain logic, and, as
such, we should be able to use it internally on the Domain, but also to communicate it to
"external actors" such as the UI and ORMs (nothing needed for the latter; it's currently implemented
on Hibernate and seems that previous specification also on DataNucleus). 

c. For viewers (including webapp, RESTful Objects, etc. but also the ORM framework - it's
just another "adapter"- detailed after), we need to give access to the domain structure (mainly
Entities, their relationships, and behavior / business rules / actions) and contextual information
about the status of the domain (and, perhaps, about the actors interacting with them, acting
as a Glue or as a "coordinator" between all those interacting with them - like using information
about the status of the ObjectStore to show in the User Interface, the Security Service, etc.).

So perhaps "a." would be my response to "auto-inferring" annotations right now... Those affecting
the Domain's behavior yes, those about internals no...

Please, tell me if any other framework is as close to Alistair Cockburn's "Ports and Adapters"
or "Hexagonal Architecture" as Apache Isis is [1].

It's interesting to read the "Nature of the Solution" section from the Apache Isis perspective.

------ Citation ------ 

"Both the user-side and the server-side problems actually are caused by the same error in
design and programming — the entanglement between the business logic and the interaction
with external entities. The asymmetry to exploit is not that between ‘’left’’ and
‘’right’’ sides of the application but between ‘’inside’’ and ‘’outside’’
of the application. The rule to obey is that code pertaining to the ‘’inside’’ part
should not leak into the ‘’outside’’ part." 

--> Me: And we have the means to communicate between inside and outside through the RESTful
Objects specification.


For each external device there is an ‘’adapter’’ that converts the API definition
to the signals needed by that device and vice versa. A graphical user interface or GUI is
an example of an adapter that maps the movements of a person to the API of the port. Other
adapters that fit the same port are automated test harnesses such as FIT or Fitnesse, batch
drivers, and any code needed for communication between applications across the enterprise
or net.


On another side of the application, the application communicates with an external entity to
get data. The protocol is typically a database protocol. From the application’s perspective,
if the database is moved from a SQL database to a flat file or any other kind of database,
the conversation across the API should not change. Additional adapters for the same port thus
include an SQL adapter, a flat file adapter, and most importantly, an adapter to a “mock”
database, one that sits in memory and doesn’t depend on the presence of the real database
at all.


Many applications have only two ports: the user-side dialog and the database-side dialog.
This gives them an asymmetric appearance, which makes it seem natural to build the application
in a one-dimensional, three-, four-, or five-layer stacked architecture.
There are two problems with these drawings. First and worst, people tend not to take the “lines”
in the layered drawing seriously. They let the application logic leak across the layer boundaries,
causing the problems mentioned above. Secondly, there may be more than two ports to the application,
so that the architecture does not fit into the one-dimensional layer drawing.
The hexagonal, or ports and adapters, architecture solves these problems by noting the symmetry
in the situation: there is an application on the inside communicating over some number of
ports with things on the outside. The items outside the application can be dealt with symmetrically.

------ End of citation ------ 

Please, excuse me for the long email. I felt I needed to contextualize with Cockburn's thoughts
.... I felt a bit insecure :-)




El 08/09/2013, a las 10:32, Dan Haywood <> escribió:

> Folks,
> Been chatting off-list with Kevin, who was the original author of the SQL
> Objectstore.  This predated the JDO objectstore but had the same basic
> intent: to persist domain objects to an RDBMS.
> Kevin originally wrote the SQL OS as the backend from apps he developed
> with Isis and the old HTML viewer.  That was in a "previous life"; there
> hasn't been any development of the SQL OS over the last couple of years.
> Since graduating we haven't ever released SQL OS as a separate component.
> Kevin says he is now happy that we mothball (ie remove from the main
> build) the SQL OS code...  if you have a reason to disagree, please speak
> now.
> ~~~
> Being a home-grown implementation, the SQL OS isn't as sophisticated as the
> JDO OS, but one advantage it does have is to require no additional
> annotations/metadata; in other words the mapping is inferred entirely from
> the Isis metamodel.
> So the next question is: do we want to enhance the JDO Objectstore so that
> it too (so far as possible) requires no JDO annotations to be defined?
> Doing some googling I notice that DataNucleus provides a writeable metadata
> API [1], so it would be possible to do this to some extent at least.
> Or, is it better to be leave things as they are, with the Isis and JDO
> annotations sitting side-by-side?  One metamodel for presentation, one for
> persistence....
> For myself, I think that if it were possible to fully specify the
> DataNucleus metamodel through Isis, then the idea has merit.  However,
> there there are concepts in DataNucleus metadata (such as the mapping of
> bidirectional relationships, the mapping of inheritance hierarchies, and
> the mapping of polymorphic references) that have no equivalent in Isis'
> metamodel.  For these, I think we would have to also support the JDO
> annotations.  One would then end up in a situation where some JDO
> annotations are inferred and implicit, but others must be specified
> explicitly.  I think that'd be quite confusing, myself.
> Any thoughts on this topic welcome.
> Thx
> Dan
> [1]

View raw message