Tanks for your reply.
One question to the tuscany frame work.
In the project the tuscany_sca_native-1.0-incubator-M3 ist used. There I can
find in the src a directory
-- src
`-- tuscany
`-- sca
|-- core
|-- extension
|-- model
`-- util
|-- core
| |-- Exceptions.cpp
| |-- Exceptions.h
| |-- Operation.cpp
| |-- Operation.h
| |-- SCARuntime.cpp
| |-- SCARuntime.h
| |-- ServiceProxy.cpp
| |-- ServiceProxy.h
| |-- ServiceWrapper.cpp
| `-- ServiceWrapper.h
|-- extension
| |-- ImplementationExtension.cpp
| |-- ImplementationExtension.h
| |-- InterfaceExtension.cpp
| |-- InterfaceExtension.h
| |-- ReferenceBindingExtension.cpp
| |-- ReferenceBindingExtension.h
| |-- ServiceBindingExtension.cpp
| `-- ServiceBindingExtension.h
In the newer version in the svn trunk i can only see a directory
|-- kernel
| |-- Makefile.am
| |-- config.hpp
| |-- dynlib-test.cpp
| |-- dynlib.hpp
| |-- element.hpp
| |-- fstream.hpp
| |-- function.hpp
| |-- gc.hpp
| |-- hash-test.cpp
| |-- hash.hpp
| |-- kernel-test.cpp
| |-- lambda-test.cpp
| |-- list.hpp
| |-- mem-test.cpp
| |-- monad.hpp
| |-- parallel-test.cpp
| |-- parallel.hpp
| |-- perf.hpp
| |-- sstream.hpp
| |-- stream.hpp
| |-- string-test.cpp
| |-- string.hpp
| |-- tree.hpp
| |-- value.hpp
| |-- xml-test.cpp
| |-- xml.hpp
| `-- xsd-test.cpp
I cannot find the corresponding files that incorporate the logic. Am i
missing something?
BR and thanks in advance,
Mario
2010/6/15 Jean-Sebastien Delfino <jsdelf...@apache.org>
> 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 <jsdelf...@apache.org>
>>
>> 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
>
--
Mit freundlichen Grüßen,
Mario Grotschar
mario.grotsc...@gmail.com
