Thanks much for the pointers and clarifying language Raymond, it really helps.
I'll poke my head up again soon when I understand Tuscany just a little better. I'll try to draw up the sample scenario as you suggest in the meantime. Seth -----Original Message----- From: Raymond Feng [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2008 6:53 PM To: [EMAIL PROTECTED] Cc: tuscany-dev Subject: Re: Guidance request for integrating Tuscany & Etch 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 >
