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...).
VISION STATEMENT:
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 ------
THE PROBLEM
"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.
CONSIDERATIONS ABOUT THE USER INTERFACE
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.
CONSIDERATIONS ABOUT THE DATABASE
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.
EXPLANATION ABOUT THE PROBLEM OF NOT ISOLATING THE DOMAIN
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 :-)
Regards,
Oscar
[1] http://alistair.cockburn.us/Hexagonal+architecture
El 08/09/2013, a las 10:32, Dan Haywood <[email protected]>
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] http://www.datanucleus.org/products/datanucleus/jdo/metadata_api.html
