Hi, Seth.
It's great to see your interest to integrate Etch with Tuscany. I think you
have covered most of the integration points. IMO, it would be quite similar
with how we integrate with CORBA. The following is a recap of the extensions
that Etch can plug in to Tuscany.
1) interface type - interface.etch: It allows SCA services and references to
use Etch as the IDL to define interfaces. It should also be possible to map
Etch IDL from/to other IDLs such as Java interface, WSDL. Some of the
interaction patterns, scoping requirements can be mapped into the SCA too.
2) binding - binding.etch: It allows SCA components to access Etch-based
services (reference binding) or expose SCA services to be Etch services
(service binding).
3) databinding - databinding-etch: Understand the Etch representations of
data and enable transformation with other databindings (such as json, xml,
JAXB, SDO).
Maybe we can try to come out a sample scenario to cover the above and use it
to drive the discussions.
Thanks,
Raymond
--------------------------------------------------
From: "Seth Call (secall)" <[EMAIL PROTECTED]>
Sent: Wednesday, November 05, 2008 2:06 PM
To: <[EMAIL PROTECTED]>
Subject: Guidance request for integrating Tuscany & Etch
Hi all,
I'm a member of the Apache Etch project, and for various reasons I've
been learning about Tuscany recently.
At a high-level, it seems Apache Etch and Apache Tuscany have a good
deal of overlap in scope. For instance, both are transport and encoding
(or 'databinding') neutral, both are extensible, both aim to support
multiple languages.
I'm interested in trying to understand how I can integrate the two in
such a way that both benefit. There are two major discrete tasks I
think would have to happen to make this possible. I'll write out what I
think there are-but I hope I can get a sanity check from this community
and make sure I'm on the right track (I'm diving into Tuscany but I only
have a very high-level understanding).
Making the 'binary' Etch transport & encoding a part of Tuscany
===============================================================
The most well-supported Etch transport/encoding is a binary encoding
over TCP or TLS. The encoding is very expressive--you can express most
any primitive and compound structures with this binary encoding. This
transport & encoding is designed to be a CPU-optimized mechanism for max
# of messages per second. Also, I should point out that Etch is a
completely IDL driven technology (you can think of a WSDL in terms of
the scope of an Etch IDL, but syntactically Etch IDL feels much closer
to a Java interface). So I believe there are 3 things one would need to
build to make a Etch module for Tuscany:
* the transport binding (i.e, something similar in scope to
binding-jsonrpc). It'd be probably called 'binding-etch' or
'binding-etch-binary'. This code would do the socket handling, and
conversion of the binary encoding into messages appropriate for the
Apache Runtime.
* the 'databinding-etch' databinding. Understands the Etch
binary format.
* A bit of code that can inspect the Tuscany service interface
as defined in the Java POJOS of a project, in order to extract out an
Etch IDL. The reason for deriving an Etch IDL is so that native Etch
clients (with no knowledge of Tuscany) can send messages to this
transport mechanism. I assume that if the WS* implementation in Tuscany
can auto-generate a WSDL from the POJOs of a Tuscany service interface,
then this piece of code would probably be very similar in scope and
nature to that.
Etch already supports C# and Java 'binary transport' clients, and are
working on C and Python actively (Ruby to follow). So if this task were
to come to life, then Tuscany offers a very useful set of tools for
clients using C#, Java, (eventually:) Python, Ruby, and C who wish to
have a very fast, two-way transport mechanism.
Making a Tuscany binding for Etch
=================================
This one I still don't understand in any technical detail, but it's
basically the reverse as above. I'll try to describe this task at a
high-level. With this task, I'd ideally want to let an Etch-built
server benefit from all the transport mechanisms available already in
Tuscany. So, ideally, I could build a 'message interceptor' in Tuscany
that would divert messages to the Etch Runtime. In other words, I'd
like to let a message coming in via any Tuscany transport binding (for
example, binding-jsonrpc and binding-ws) be sent to the Etch runtime,
and the Etch runtime turns around and calls the appropriate method on
the Java POJO as per usual in Etch once a message has come in. I think
maybe I could build a Tuscany Translator for this? (or if I understand
translators correctly, I think I'd have to build one for every target
databinding I want to support coming in from a client?). The reason
for building this would be for people who are working with the Etch
toolset, but want a lot of the benefit of the various Tuscany transports
and databindings.
The big issue in either case is a mismatch of features and concepts.
Both Etch and Tuscany support methods, various data types, exceptions,
oneway calls, asynchronous notifications, sessions. But one difference
I already see is the concept of a 'conversation' in Tuscany--there is no
way to formally describe such a thing in an Etch IDL (although we've
actually talked about supporting the same concept in the past). I'm
sure there are more. And truthfully I think the only way to really
navigate this particular problem is for someone to deeply understand
both Etch and Tuscany.
Anyway, all I'm asking is any sort of validation the community might be
able to make on these thoughts. Just as helpful are concrete Tuscany
terms, which would help me while reading the Tuscany documentation and
reading over the Tuscany code... which I'll head back into now.
Thanks for any help!
Seth
