lightweight generic technology-agnostic API for domain-driven applications

[Rafael Chaves <ra...@abstratt.com>]

I'd like to see a lightweight generic technology-agnostic API that gave
access to the functionality of domain-driven applications.

Generic, because it would provide generic abstractions for doing CRUD and
invoking actions and queries, based on sufficient schema metadata.

Technology-agnostic because it would be purely specification, the actual
behavior would need to be provided by supporting implementations (Isis,
OpenXava, Grails etc). Also, being easy to translate to other languages
would be a primary design goal.

Think Restful Objects but without hitting the network.

Think Isis without the runtime support and user's domain-specific Java
classes.

I have seen the isis-metamodel-core component, but it seems much
richer/more complex than necessary. Exposing similar functionality as RO
would require a much simpler spec I believe. Agreed?

Then, if instead of Isis-specific viewers we had viewers built on this API,
we could run them against a much wider range of stacks that Isis will ever
provide. Since they would be used in many different contexts, it would be
easier to get more people on-board to develop them (not only those
interested in Isis, or Grails etc).

Disclaimer: I develop a service that while not Isis or RO-based, is also
domain-driven. I developed a couple of "viewers" (Qooxdoo UI and a REST
API), and am considering an Android one, and I wish I didn't have to, or at
least that they were reusable in other contexts.

I published a similar API that I built for using in Cloudfier here:

http://bitbucket.org/abstratt/kirra-api/

See how small it is. Yet it allows me to build generic clients that don't
know what kind of runtime the accessed functionality is running on. Please
don't get hung up on details - I'd be happy to drop it in favor of
something new (built collaboratively with folks from Isis, OpenXava, Naked
Objects etc). I decided to publish it as open-source just to get the
conversation started.

So, pipe dream, or a doable endeavor?

Cheers,

Rafael

Re: lightweight generic technology-agnostic API for domain-driven applications

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Rafael,

This is a nice piece of work; I've thought about formalizing the Isis API
for a while.  If it were cross-framework, so much the better.  The
analogies with RO are well made;  in the future we expect to get a
cross-framework viewers conformant to the RO API.

I dimly recall similar conversations with Oscar too; in their app they
don't use the Wicket viewer, instead have a viewer implemented on
WaveMaker.  They are having to reach into Isis' internals, I am sure a
simpler API would be welcome.  Oscar?

I didn't try to grok the entire codebase, but looking over it it does seem
to be put together by someone who knows what they're doing :-)

A couple of observations, though:
* I see an isRequired() flag, eg [1], but this doesn't seem to be
extensible.  One of the bits of the Isis metamodel that has worked really
well is the concept of facets (basically the ExtensionObject pattern used
all over the place in the Eclipse codebase); would be worth adding that in
* Related, I see an isEditable() method [2].  Isis in contrast has three
levels of checking: visibility, editabilty and then validation ("see it,
use it, do it").  In fact, this overlaps with the facets, that can
optionally implement HidingInteractionAdvisor, DisablingInteractionAdvisor
and ValidatingInteractionAdvisor.  So without support for this in the API,
none of Isis' behaviour here could be surfaced.
* in the API I see some methods (master/child table, [3]) that suggest a
very particular UI is in mind.  Not sure about that.

And from a style viewpoint
* equals/hashCode for an abstract class; not sure Josh Bloch would condone
that... [4]
* would it not make sense to make everything immutable?  Isis' metamodel
isn't, and it pains me.

In terms of implementing this in Isis; well it's nowhere near the top of my
priority list (RO and the next-gen viewer are priorities).  But I'd be very
happy to support you if you wanted to build an Isis implementation
yourself.  Perhaps others might be interested in helping.

By the way, if you can get to Milan for our mini-conf [5] in a few weeks
time, would be great to see you.  (Offer open to all).

Cheers
Dan


[1]
https://bitbucket.org/abstratt/kirra-api/src/7e3a0f4dbd8fd810b15208e23cacb515ba1136fd/com.abstratt.kirra.api/src/com/abstratt/kirra/TypedElement.java?at=master#cl-14
[2]
https://bitbucket.org/abstratt/kirra-api/src/7e3a0f4dbd8fd810b15208e23cacb515ba1136fd/com.abstratt.kirra.api/src/com/abstratt/kirra/DataElement.java?at=master#cl-40
[3]
https://bitbucket.org/abstratt/kirra-api/src/7e3a0f4dbd8fd810b15208e23cacb515ba1136fd/com.abstratt.kirra.api/src/com/abstratt/kirra/DataElement.java?at=master#cl-13
[4]
https://bitbucket.org/abstratt/kirra-api/src/7e3a0f4dbd8fd810b15208e23cacb515ba1136fd/com.abstratt.kirra.api/src/com/abstratt/kirra/TypedElement.java?at=master#cl-39
[5] https://cwiki.apache.org/confluence/display/ISIS/IsisCon+2014




On 8 May 2014 15:28, Rafael Chaves <ra...@abstratt.com> wrote:

> I'd like to see a lightweight generic technology-agnostic API that gave
> access to the functionality of domain-driven applications.
>
> Generic, because it would provide generic abstractions for doing CRUD and
> invoking actions and queries, based on sufficient schema metadata.
>
> Technology-agnostic because it would be purely specification, the actual
> behavior would need to be provided by supporting implementations (Isis,
> OpenXava, Grails etc). Also, being easy to translate to other languages
> would be a primary design goal.
>
> Think Restful Objects but without hitting the network.
>
> Think Isis without the runtime support and user's domain-specific Java
> classes.
>
> I have seen the isis-metamodel-core component, but it seems much
> richer/more complex than necessary. Exposing similar functionality as RO
> would require a much simpler spec I believe. Agreed?
>
> Then, if instead of Isis-specific viewers we had viewers built on this API,
> we could run them against a much wider range of stacks that Isis will ever
> provide. Since they would be used in many different contexts, it would be
> easier to get more people on-board to develop them (not only those
> interested in Isis, or Grails etc).
>
> Disclaimer: I develop a service that while not Isis or RO-based, is also
> domain-driven. I developed a couple of "viewers" (Qooxdoo UI and a REST
> API), and am considering an Android one, and I wish I didn't have to, or at
> least that they were reusable in other contexts.
>
> I published a similar API that I built for using in Cloudfier here:
>
> http://bitbucket.org/abstratt/kirra-api/
>
> See how small it is. Yet it allows me to build generic clients that don't
> know what kind of runtime the accessed functionality is running on. Please
> don't get hung up on details - I'd be happy to drop it in favor of
> something new (built collaboratively with folks from Isis, OpenXava, Naked
> Objects etc). I decided to publish it as open-source just to get the
> conversation started.
>
> So, pipe dream, or a doable endeavor?
>
> Cheers,
>
> Rafael
>