Thanks for this good explanation. In the course of an university project, I would like to write a queue binding, most likely using qpid. As I understand the advantage of a real binding, is that its more transparent and you can use the interceptors for formatting etc. Is there any other advantage?
For the java version there is some introduction on how to extend the runtime. Is there something similar for the c++ version? 2010/6/3 Jean-Sebastien Delfino <[email protected]> > Mario Grotschar wrote: > >> One more question :-). I have noticed that in the Java Framework of >> Tuscany >> there is a JMS binding. Does Tuscany Java come with an embedded >> JMS-Provider? >> > > The Tuscany 1.x Java distributions include Apache ActiveMQ. > > I couldn't find ActiveMQ in the Tuscany 2.x Java distributions, but that's > what the 2.x test cases use as well. > > > Is there a specific reason why qpid was implemented as a >> component and not integrated as a binding in the Native Tuscany? >> > > It was just simpler for me to write an application component than extend > the runtime with plumbing code to define and support a specific binding. > > The syntax with a component is a little different. For example, say I have > a component "Foo", with a reference "bar" used to send messages to Qpid with > key "xyz". > > With a full blown Qpid binding I'd be able to write something like: > <component name="Foo"> > <t:implementation.python script="foo.py"/> > <reference name="bar"> > <t:binding.qpid> > <key>xyz</key> > </t:binding.qpid> > </reference> > </component> > > With a Qpid component, I have to write: > <component name="Foo"> > <t:implementation.python script="foo.py"/> > <reference name="bar" target="Bar"/> > </component> > > <component name="Bar"> > <implementation.cpp library="liqueue-sender"/> > <property name="key">xyz</property> > </component> > > That approach has been working OK for me though. I even discovered some > benefits after a while. For example Bar can be moved to another machine, or > replaced with a completely different component implementation (say, using a > database instead of a Qpid queue), without changing Foo's configuration at > all. > > If anybody wants to go beyond the basic component approach and develop a > real binding, please jump in and I will try to help you, in the very limited > spare time I can spend on this. > > > > > Is there also a high level overview of the Tuscany Native runtime such as > >> for the Java version? >> >> > No, but there's not so much code to read :) > > In a nutshell, it's a thin C++ runtime that plugs into the Apache HTTPD > server to dispatch HTTP requests and route them along SCA wires to SCA app > components. > > Components can be written in C++, Python or a subset of Scheme (mostly used > for self contained tests not requiring Python integration). > > There's experimental support for Java components, but it's too rough and > limited to be really useful. > > A small subset of the SCA assembly model is supported, without policies or > SCA contributions, but enough to run apps like the "Store" sample app > available on the Tuscany Java runtime for example. > > SCA bindings are provided for the JSON-RPC and AtomPub protocols. > > In addition to the runtime, there's a few C++ components that can help > integrate an SCA app with Qpid, Axis2, Vysper, Scribe logging servers etc. > They bring dependencies on these various packages but they're optional, so > don't build them if you don't need them. > > A little more info can be found in the README and INSTALL files in the > sca-cpp trunk [1]. > > That was three more questions :) Hope this helps. > > > [1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/ > -- > Jean-Sebastien > -- Mit freundlichen Grüßen, Mario Grotschar [email protected]
