etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman" <>
Subject Re: Dynamic Service interfaces?
Date Tue, 13 Jan 2009 19:57:36 GMT
On Tue, Jan 13, 2009 at 6:31 PM, scott comer (sccomer)
<> wrote:
> perhaps you could illustrate for me what you are trying to do or want to do.
> have you actually built something in etch yet?

I have not built something yet. But I can see the potential,
especially if few things "are taken care of"...

I am coming from the Java world, but I can appreciate multi-platform
interoperability. To explain my "vision", I need to give some

My framework (Qi4j) has a "Service" concept that are split in 2.
 - Hosted Service
 - Imported Service

Hosted Service is written for the Qi4j framework, and the lifecycle is
managed by the Qi4j Runtime. It is fairly simple to create an
"exporter" of the service to a foreign system, as Qi4j has a strong
model and enforcement of application architecture (layer, modules with
visibility rules).

Imported Service is something external, that is registered into Qi4j
as being available.

Both are either injected to clients or looked up via a ServiceFinder.

The easy part of Etch integration to Qi4j would be to consume Etch
services, since the service creator are responsible to hand a Java
binding for it, which I think we can simply provide as an Imported
service. In principle, no big deal, just a matter of trying it out.

BUT, I would also like to be able to make any Qi4j Service, hosted or
imported, exposed as a networked service, simply by installing an
EtchExporter library to any Qi4j application. I can accept that there
are severe limitations on method arguments and return types, but it is
not feasible if;

  - The solution is not easily testable. (unclear on this point at the moment)
  - The Etch IDL is required to be written by the Java developer. Need
to generate FROM a Java interface.

And I think the above can be done with development tools, BUT that
introduces a nightmare, since we in such case probably need to support
multiple IDEs, Maven, Ant and possibly 'stand-alone'. Requiring
tooling ain't "Nice", so the framework can generate the IDL, convert
IDL to any and all client bindings supported, BUT generation of
service bindings will require the java compiler, which ain't
acceptable (can't require JDK installed on downstream user's
AND, if the framework handles everything "under the hood", the service
IDLs could be downloadable straight from the service providing
instance for consumption of other clients. Throw in a request
parameter for the C# source code to quickly get going as a client, and
now we are talking 'simpler use'.

I hope this gives a brief overview of what I have in mind. To recap;
 - Qi4j binds marked Services as Etch services to the network.
 - Qi4j produces (if possible) the Etch IDL from Java service interface.
 - Qi4j mounts the the IDL on a URL automatically.
 - Qi4j generates the client binding code automatically and mounts on URLs.

-- - New Energy for Java

View raw message