You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Seth Call (secall)" <se...@cisco.com> on 2008/11/05 23:06:02 UTC
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
RE: Guidance request for integrating Tuscany & Etch
Posted by "Seth Call (secall)" <se...@cisco.com>.
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:enjoyjava@gmail.com]
Sent: Wednesday, November 05, 2008 6:53 PM
To: user@tuscany.apache.org
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)" <se...@cisco.com>
Sent: Wednesday, November 05, 2008 2:06 PM
To: <us...@tuscany.apache.org>
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
>
RE: Guidance request for integrating Tuscany & Etch
Posted by "Seth Call (secall)" <se...@cisco.com>.
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:enjoyjava@gmail.com]
Sent: Wednesday, November 05, 2008 6:53 PM
To: user@tuscany.apache.org
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)" <se...@cisco.com>
Sent: Wednesday, November 05, 2008 2:06 PM
To: <us...@tuscany.apache.org>
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
>
Re: Guidance request for integrating Tuscany & Etch
Posted by Raymond Feng <en...@gmail.com>.
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)" <se...@cisco.com>
Sent: Wednesday, November 05, 2008 2:06 PM
To: <us...@tuscany.apache.org>
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
>
Re: Guidance request for integrating Tuscany & Etch
Posted by Raymond Feng <en...@gmail.com>.
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)" <se...@cisco.com>
Sent: Wednesday, November 05, 2008 2:06 PM
To: <us...@tuscany.apache.org>
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
>