You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2013/09/08 10:32:35 UTC
[DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO
annotations from Isis conventions
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
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Just for clarification.
An indicator that we need to enhance the meta model would be when one adapter (ie the UI viewer) needs information about other adapter to properly function (such as the validation rules or the ORM annotations).
El 08/09/2013, a las 11:37, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> escribió:
>
> 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).
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO
annotations from Isis conventions
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 10 September 2013 19:28, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
> I would be interested in knowing if it is possible to use the DN meta
> data API to allow the JDO data store to make intelligent guesses
> (that'll generally be "right", or at least a default that is generally
> useable).
>
Yes, I think that by and large that would be possible. Certainly, a lot of
the Estatio entities are all very similar to each other.
I could also imagine "profiles" whereby we map one way for a "typical"
RDBMS setup, and a slightly different way to support Google App Engine.
(Maurizio tells me off-list that this is working fine; he's in the middle
of getting his committer perms sorted in order to do the necessary commit).
>
> Then, when the defaults are not good enough (some final deployment
> tweaking would improve behaviour or performance), let the developer
> provide JDO annotations as required.
>
>
Yeah, I think that would be necessary.
> Of course, some Isis annotations (e.g. @Optional) also impact on the
> database (implicitly requiring "allowNulls = true") and there is possibly
> no way around this (unless one of the defaults to the datastore is that
> allowNulls is always true!)
>
>
At the moment we have Isis recognizing @Column(allowsNull=true) to mean
optional. But if we use the DN metadata API, then we could go the other
way (ie use @Optional to setup the DN metamodel instead).
So goal is to get the objectstore "working" as soon as possible with no
> (or very few) data-store specific annotations on the POJOs.
>
>
Very happy to support you on this Kevin. For myself, I shan't be putting
any time into it; need to keep focussed on getting Estatio live.
> So, the question is: Can the metadata API provide enough input to
> DN that an introspector (using the Isis metamodel) can guess the
> required DN metadata for entities and properties (single valued and
> collections) if there are no annotations?
>
>
To a large extent, yes. The main things we don't have are bidirectional
relationships and inheritance mapping (roll-up vs table-per-type vs
roll-down). For these I think we just recognize the JDO annotations.
> I don't understand the relationship between JDO and DN, so I would
> need to do a lot of research first.. ;)
JDO is the API, DN is the implementation. (DN also supports the JPA API,
so after we get this sorted out to our mutual satisfaction, we can go round
the loop and look at JPA).
> Perhaps a better understanding
> would clarify why my goal is pointless (or impossible).
>
>
It's doable. The question remains: do we expect our would-be users to
learn the Isis conventions (and learn about its default mappings), or do we
let them bring their existing JDO (and one day) JPA knowledge and then have
Isis do "the right thing".
Dan
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
I am not proposing the hints be provided by a config file again, and I
don't propose that a new "Isis specific" object store annotation
vocabulary be developed.
I would be interested in knowing if it is possible to use the DN meta
data API to allow the JDO data store to make intelligent guesses
(that'll generally be "right", or at least a default that is generally
useable).
If the un-annotated POJOs end up with a generally useable datastore,
that'll be wonderful.
Then, when the defaults are not good enough (some final deployment
tweaking would improve behaviour or performance), let the developer
provide JDO annotations as required.
Of course, some Isis annotations (e.g. @Optional) also impact on the
database (implicitly requiring "allowNulls = true") and there is possibly
no way around this (unless one of the defaults to the datastore is that
allowNulls is always true!)
So goal is to get the objectstore "working" as soon as possible with no
(or very few) data-store specific annotations on the POJOs.
So, the question is: Can the metadata API provide enough input to
DN that an introspector (using the Isis metamodel) can guess the
required DN metadata for entities and properties (single valued and
collections) if there are no annotations?
I don't understand the relationship between JDO and DN, so I would
need to do a lot of research first.. ;) Perhaps a better understanding
would clarify why my goal is pointless (or impossible).
> Yes, it's true that we now have the Isis metadata as secondary to the JDO
> annotations.
>
> This breaks symmetry and means that, to deploy Isis against a different
> ObjectStore, that at best those JDO annotations are redundant, at worst one
> that one would have put in equivalent metadata for the other OS (eg SQL OS'
> properties).
>
> As mentioned, we could invert this. Using the DataNucleus metadata API
> [1], we could programmatically build up the DataNucleus metamodel from the
> Isis metamodel. Where required, we could also recognize some subset of the
> JDO annotations that have no Isis equivalent (eg "mappedBy" for
> bidirectional annotations). Or, I suppose, we could add in our own
> equivalent Isis annotations.
>
> I'm not convinced that this is the right thing to do though, for two
> reasons ...
[1] http://www.datanucleus.org/products/datanucleus/jdo/metadata_api.html
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Mmmm... I understand those arguments.
Just for doing a "lateral thinking exercise" and question the current status, I'm going to question some things :-)
In practice, if taken until the end, what that would implied, is:
- that we should remove the Isis' @Optional annotation (among others).
- that we would implement some Facets for the meta-model that would not have a corresponding Isis annotation (so the Isis "metadata" would not be "complete" in terms of its own meta-model).
- that we are always going to use on Isis webapps JDO as the ORM metadata (if one decision criteria is "number of developers" it will be important to support JPA in the future),
- that we are always going to use on Isis webapps DN as an object store (I'm happy with this right now),
- that we are always going to use on Isis webapps an object store in our apps, and use cases where it's not present would not be "Isis" use cases (unless we mark all entities as transient or something like that; not clear to me...). For example, we have an IT Real-time Monitoring Bounded Context where we want to use Isis. On that BC we would not have available those Isis features (whatever they will be in the future).
My opinion, a corresponding Isis annotation would be needed for any Facet, but to be concrete:
- for Facets that change the domain's behavior (such as the managed relationships; my code is becoming full of "flush()'es" just for updating the parent collection's size; this could be managed by Isis instead of delegating to DN).
- for Facets corresponding to behaviors delegated to one adapter's implementation that will be maintained "as-is" that can be required to be known by other adapters (such as mandatory properties, or imagine that we apply some bean validations on the UI for avoiding network traffic, so the UI would need "access" through the meta-model to those validations, etc.).
But this is "just" a theroretical discussion regarding a "long-term" vision.
Perhaps the KISS principle dictates to avoid any functionality "duplication".
So it's also interesting to consider the costs to avoid previous handicaps, that I think would be:
- in terms of implementation, simply to have an Isis annotation for specifying the Facet's behavior.
- in terms of maintainability, update it when the Facet behavior changes (that would imply also a change on the adapter that implements the delegated behavior - i.e. the objectstore or any other "adapter" that provides it -).
Perhaps they would be manageable for most cases, and we could align with the (at least my) vision.
Thanks,
Oscar
El 09/09/2013, a las 08:55, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 8 September 2013 11:55, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>>> 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(allowsNull="true|false"), instead of improving the JDO
>>> Object Store usage of the Isis meta-model.
>>
>> When I first started with Isis (when it was still Naked Objects), I was
>> really drawn to the fact that any POJO that I prototyped could be
>> re-used "as is" elsewhere, as it contained no "framework" clutter.
>>
>> As Oscar says, this is now exactly the opposite. If the assumption is
>> that Isis will always be the deployment framework, this is just fine!
>>
>>> 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.
>>
>> In the SQL OS, I provided for "hints" to be specified in the properties
>> file (overriding property-field mappings, table naming, etc) (and
>> Eclipse could handle refactoring/renaming if the full name name was
>> used in the properties file) - leaving the POJO clean of DB clutter.
>>
>>
> Yes, it's true that we now have the Isis metadata as secondary to the JDO
> annotations.
>
> This breaks symmetry and means that, to deploy Isis against a different
> ObjectStore, that at best those JDO annotations are redundant, at worst one
> that one would have put in equivalent metadata for the other OS (eg SQL OS'
> properties).
>
> As mentioned, we could invert this. Using the DataNucleus metadata API
> [1], we could programmatically build up the DataNucleus metamodel from the
> Isis metamodel. Where required, we could also recognize some subset of the
> JDO annotations that have no Isis equivalent (eg "mappedBy" for
> bidirectional annotations). Or, I suppose, we could add in our own
> equivalent Isis annotations.
>
> I'm not convinced that this is the right thing to do though, for two
> reasons:
>
> 1. there are many potential users out there that understand JDO (and JPA,
> of course, when we get around to support it's annotations). Requiring them
> to learn the Isis equivalents is going to put them off.
>
> 2. I don't think that being able to switch between object stores is that
> significant. While presentation/UIs are fashion items that change every
> few years, the data in a production database tends to stay where it is.
> Indeed, the application/domain model itself is more volatile than the
> data; right now over in Ireland we are building a replacement naked objects
> app to the original, against the same physical DB schema, but with a
> changed domain model in certain cases.
>
> Putting my cards on the table, I would rather that Isis leverage
> DataNucleus for handling different persistence mechanisms through DN's own
> StoreManager API [2]. Using Oscar's terminology, DN's goal is to provide
> the ports and adapters (of the hexagonal architecture) for persistence,
> while Isis handles the the ports and adapters everything else
> (presentation/UI in particular).
>
> What I also want to do, long term, is to deprecate all the other Isis
> object stores and eventually remove them. We could then start to simplify
> Isis internally.
>
> Obviously, this is for the community to decide on this, but it's where I
> currently stand.
>
> It's worth noting that on Naked Objects.NET, they are following an
> equivalent path, where they just use an ObjectStore based on Microsoft's
> Entity Framework. In fact, they are going further: where there is an EF
> metadata annotation, they are deprecating their NO-specific one. They have
> also already dumped all their other object stores bar their in-memory
> object store.
>
> Thx
> Dan
>
> [1] http://www.datanucleus.org/products/datanucleus/jdo/metadata_api.html
> [2] http://www.datanucleus.org/extensions/store_manager.html
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO
annotations from Isis conventions
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 8 September 2013 11:55, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> > 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(allowsNull="true|false"), instead of improving the JDO
> > Object Store usage of the Isis meta-model.
>
> When I first started with Isis (when it was still Naked Objects), I was
> really drawn to the fact that any POJO that I prototyped could be
> re-used "as is" elsewhere, as it contained no "framework" clutter.
>
> As Oscar says, this is now exactly the opposite. If the assumption is
> that Isis will always be the deployment framework, this is just fine!
>
> > 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.
>
> In the SQL OS, I provided for "hints" to be specified in the properties
> file (overriding property-field mappings, table naming, etc) (and
> Eclipse could handle refactoring/renaming if the full name name was
> used in the properties file) - leaving the POJO clean of DB clutter.
>
>
Yes, it's true that we now have the Isis metadata as secondary to the JDO
annotations.
This breaks symmetry and means that, to deploy Isis against a different
ObjectStore, that at best those JDO annotations are redundant, at worst one
that one would have put in equivalent metadata for the other OS (eg SQL OS'
properties).
As mentioned, we could invert this. Using the DataNucleus metadata API
[1], we could programmatically build up the DataNucleus metamodel from the
Isis metamodel. Where required, we could also recognize some subset of the
JDO annotations that have no Isis equivalent (eg "mappedBy" for
bidirectional annotations). Or, I suppose, we could add in our own
equivalent Isis annotations.
I'm not convinced that this is the right thing to do though, for two
reasons:
1. there are many potential users out there that understand JDO (and JPA,
of course, when we get around to support it's annotations). Requiring them
to learn the Isis equivalents is going to put them off.
2. I don't think that being able to switch between object stores is that
significant. While presentation/UIs are fashion items that change every
few years, the data in a production database tends to stay where it is.
Indeed, the application/domain model itself is more volatile than the
data; right now over in Ireland we are building a replacement naked objects
app to the original, against the same physical DB schema, but with a
changed domain model in certain cases.
Putting my cards on the table, I would rather that Isis leverage
DataNucleus for handling different persistence mechanisms through DN's own
StoreManager API [2]. Using Oscar's terminology, DN's goal is to provide
the ports and adapters (of the hexagonal architecture) for persistence,
while Isis handles the the ports and adapters everything else
(presentation/UI in particular).
What I also want to do, long term, is to deprecate all the other Isis
object stores and eventually remove them. We could then start to simplify
Isis internally.
Obviously, this is for the community to decide on this, but it's where I
currently stand.
It's worth noting that on Naked Objects.NET, they are following an
equivalent path, where they just use an ObjectStore based on Microsoft's
Entity Framework. In fact, they are going further: where there is an EF
metadata annotation, they are deprecating their NO-specific one. They have
also already dumped all their other object stores bar their in-memory
object store.
Thx
Dan
[1] http://www.datanucleus.org/products/datanucleus/jdo/metadata_api.html
[2] http://www.datanucleus.org/extensions/store_manager.html
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
> 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.
I assume this a typo and you meant "@Column(allowsNull ...)"..
When I first started with Isis (when it was still Naked Objects), I was
really drawn to the fact that any POJO that I prototyped could be
re-used "as is" elsewhere, as it contained no "framework" clutter.
As Oscar says, this is now exactly the opposite. If the assumption is
that Isis will always be the deployment framework, this is just fine!
> 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.
In the SQL OS, I provided for "hints" to be specified in the properties
file (overriding property-field mappings, table naming, etc) (and
Eclipse could handle refactoring/renaming if the full name name was
used in the properties file) - leaving the POJO clean of DB clutter.
BTW: I certainly don't want to suggest that Isis should use manually
maintained xml files! Although, if memory serves, Apache Cayenne
[1] has a modelling tool (Cayenne Modeler) to manage generating the
schema data. Again, I'm not suggesting this as a recommended tool
for Isis.
Oscar, thanks for reproducing the cited text. It neatly highlights the
"edges" and the ease & associate problems with responsibility
leakage.
Regards,
Kevin
[1] http://cayenne.apache.org/
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Just for clarification.
An indicator that we need to enhance the meta model would be when one adapter (ie the UI viewer) needs information about other adapter to properly function (such as the validation rules or the ORM annotations).
El 08/09/2013, a las 11:37, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> escribió:
>
> 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).
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@haywood-associates.co.uk> 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
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
> Kevin originally wrote the SQL OS as the backend from apps he developed
> with Isis and the old HTML viewer.
Umm. Not quite. I believe Rob developed the original SQL OS, I just
took it over and extended it (added polymorphism, collections of the
same type as the parent within the parent, and a few other tweaks).
> ~~~
>
> 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.
>
> [snip]
>
> 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.
I would need to spend a bit of time looking at the relationship between
JDO and DN, and seeing where the holes are.. Dan, I will be in touch
;)
Regards,
Kevin
Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
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 <da...@haywood-associates.co.uk> 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