Mario Grotschar wrote:
Thanks for this good explanation.
Hi, sorry for the delay responding, I'm on vacation, traveling with
limited access to email.
In the course of an university project, I would like to write a queue
binding, most likely using qpid.
Great! I'll try to help you as much as possible.
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?
It really depends on what you mean by transparent. A binding requires
you to add a <binding.qpid> element to your service or reference. As
shown in the .composite snippets below, a component allows you to push
the Qpid configuration further away from your application component, in
another component. So one could argue that a component is more
'transparent'.
It would be interesting to hear opinions from other Tuscany developers
and users on this.
In terms of runtime complexity, a binding may allow you to save a hop
through another component, at the expense of more runtime plumbing.
For example, imagine you want to bind a particular service to SOAP /
Axis2c, Apache Thrift and Qpidc. You'll probably have to create four
processes (or threads):
1) HTTPD configured with Axis2C for SOAP
2) a Thrift server
3) a Qpidc listener
4) a process running your component implementation
and some inter-process/thread communication between 1/2/3 and 4.
Doesn't that look similar to four components? :)
For the java version there is some introduction on how to extend the
runtime. Is there something similar for the c++ version?
Yes, in this email :)
Here are several ways to extend the runtime with a new binding:
a) Read the .composite containing the binding configuration and
translate it to an equivalent .composite containing a component
configuration. I'd suggest that approach as a first step, as it'll allow
you to experiment with the binding configuration (and refine the SCDL
language extension for that binding) without requiring new runtime
plumbing. You'll find code to read SCDL in modules/scdl [2].
b) For a service binding, implement a server process that listens on the
particular protocol you want to support in the binding (a Qpid listener
here) and dispatches/relays messages to the application component
providing the service (easy to do with the proxy functions in
modules/http [3]).
c) For a reference binding, make a small change to the mkrefProxy
function in mod-eval.hpp [4] to create Qpid proxies in addition to HTTP
proxies, or come up with a generic and extensible mkrefProxy function
that looks at the binding configuration to create the proper proxy type.
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
[2] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/scdl
[3] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/http
[4]
http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/server/mod-eval.hpp
Hope this helps
--
Jean-Sebastien
