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

Reply via email to