You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2008/06/27 17:45:06 UTC
JNI-based C/C++ component implementation for SCA: was: Re: AW: Apache Tuscany doubts
Hi, Simon.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Friday, June 27, 2008 5:15 AM
To: <us...@tuscany.apache.org>
Subject: Re: AW: Apache Tuscany doubts
> Hi Raymond
>
> Nice idea. Comments in line...
>
> If we did want to fully support C++ classes as SCA components, i.e. with
> references and all the trimings then we could look to use the native
> runtime
> in the same domain, as opposed to in the same VM. Embedding it might be
> tricky.
Yes. There are two SCA runtimes in Tuscany, one is implemented in Java and
the other in C++. But it should also be possible for the Java runtime to
host C/C++ components and vice versa.
>
> Simon
>
> On Thu, Jun 26, 2008 at 7:16 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> Can you describe the use cases you have in mind? It will help us better
>> understand what you want to achieve.
>>
>> Are you interested in contributing in this area? I can give some pointers
>> and thoughts to get you started. The following is based on my
>> on-the-surface
>> thoughts.
>>
>> For example, you have a C/C++ DLL which provides some business functions
>> and you want to use them to implement SCA components.
>>
>> As the first step, you can even use implementation.java to call JNI and
>> you
>> just have to write an implementation class like:
>>
>> @Service(Calculator.class)
>> public class JNICalculatorImpl implements Calculator {
>> static {
>> System.loadLibrary("calculator.dll");
>> }
>> public native int method calculate(String op, int n1, int n2);
>>
>> @Reference
>> public Add addService;
>> }
>>
>> And configure the component as:
>>
>> <component name="JNICalculatorComponent">
>> <implementation.java class="calculator.dll"/>
>> </component>
>
>
> Did you mean ...
>
> <implementation.java class="JNICalculatorImpl "/>
>
Yes, that's what I meant. Thank you for correcting it.
>
>>
>> For the second step, we can try to automate the JNI access as follows:
>>
>> 1) Model the component as implementation.jni:
>>
>> <component name="JNICalculatorComponent">
>> <implementation.jni library="calculator.dll"/>
>> </component>
>>
>> You also need to provide a componentType file to describe the JNI
>> operations (Potentially we can introspect the native C++ interface).
>>
>> <componentType>
>> <service name="Calculator">
>> <interface.java interface="calculator.Calculator"/> <!-- This is
>> the
>> java interface for the JNI functions -->
>> </service>
>> <reference name="Add">
>> <interface.java interface="calculator.Add"/> <!-- This is the java
>> interface for the JNI functions -->
>> </service>
>> </componentType>
>>
>> Then we can generate the JNICalculatorImpl class as illustrated above to
>> represent the JNI component using ASM.
>
>
> This looks like a promising and straightforward idea to get dlls working
> as
> component implementations. In the native runtime there is a Java scagen
> tool
> that does C++ header file introspection. Its for generating C++ service
> proxy classes but there may be some code that is of use there if there is
> a
> requirement to do instropection in this case
>
It would be great if we can introspect the C++ header file to create a
componentType for the C++ components.
>
>
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: ""Dietrich, Björn"" <B....@cenit.de>
>> Sent: Wednesday, June 25, 2008 11:45 PM
>> To: <us...@tuscany.apache.org>
>> Subject: AW: Apache Tuscany doubts
>>
>>
>> Hi,
>>>
>>> We are also looking for native (JNI) binding between Java and C++,
>>> This would be a real cool feature.
>>>
>>> Greetings
>>> Björn
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Malte Marquarding [mailto:malte.marquarding@gmail.com]
>>> Gesendet: Donnerstag, 26. Juni 2008 02:51
>>> An: user@tuscany.apache.org
>>> Betreff: Re: Apache Tuscany doubts
>>>
>>> Hi,
>>>
>>> Is there a timeline for the java runtime hosting a c++ component? We are
>>> currently evaluating tuscany and need to access c++ components as these
>>> are
>>> needed for specialized algorithms.
>>>
>>>
>>> Cheers,
>>> Malte.
>>>
>>>
>>> At this point, Tuscany has both Java and C++ for 1). But the java
>>>> runtime doesn't support C++ component, and not C++ runtime supports
>>>> Java component either. So we have to use different runtimes to host
>>>> the C++ and Java components at this point, but it's potentially
>>>> possible that the Java runtime will be capable of hosting C++
>>>> component.
>>>>
>>>>
>>>
>>> CENIT AG Systemhaus, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49
>>> 711 7825-30, Fax: +49 711 7825-4000, Internet: www.cenit.de
>>> Geschaeftsstellen: Berlin, Duesseldorf, Frankfurt, Hamburg, Hannover,
>>> Muenchen, Saarbruecken
>>> Vorstandsmitglieder: Kurt Bengel, Christian Pusch
>>> Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des
>>> Aufsichtsrats),
>>> Hubert Leypoldt, Andreas Karrer
>>> Bankverbindungen:
>>> Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166
>>> 1040 00 SWIFT-CODE : DEUTDESS,
>>> Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532
>>> 0155 00 SWIFT-Code : COBADEFF600,
>>> BW-Bank (BLZ 600 501 01) Kto. 2 403 313 IBAN : DE17 6005 0101 0002 4033
>>> 13
>>> SWIFT-Code : SOLADEST
>>> Registergericht: Amtsgericht Stuttgart
>>> Handelsregister: HRB Nr. 19117
>>> Umsatzsteuer: ID-Nr. DE 147 862 777
>>>
>>>
>
Re: JNI-based C/C++ component implementation for SCA: was: Re: AW:
Apache Tuscany doubts
Posted by Simon Nash <na...@apache.org>.
One comment inline.
Simon
Raymond Feng wrote:
> Hi, Simon.
>
> Please see my comments inline.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Simon Laws" <si...@googlemail.com>
> Sent: Friday, June 27, 2008 5:15 AM
> To: <us...@tuscany.apache.org>
> Subject: Re: AW: Apache Tuscany doubts
>
>> Hi Raymond
>>
>> Nice idea. Comments in line...
>>
>> If we did want to fully support C++ classes as SCA components, i.e. with
>> references and all the trimings then we could look to use the native
>> runtime
>> in the same domain, as opposed to in the same VM. Embedding it might be
>> tricky.
>
> Yes. There are two SCA runtimes in Tuscany, one is implemented in Java
> and the other in C++. But it should also be possible for the Java
> runtime to host C/C++ components and vice versa.
>
I am not so convinced about this. The strength of SOA is that you
don't need a single runtime, but can federate your services across
different runtimes running either locally or remotely. I think it's
better to focus our efforts in this area on getting the two Tuscany
SCA runtimes to federate well together, rather than on making the
Java runtime a first-class hosting environment for C++ components.
Simon
>>
>> Simon
>>
>> On Thu, Jun 26, 2008 at 7:16 PM, Raymond Feng <en...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Can you describe the use cases you have in mind? It will help us better
>>> understand what you want to achieve.
>>>
>>> Are you interested in contributing in this area? I can give some
>>> pointers
>>> and thoughts to get you started. The following is based on my
>>> on-the-surface
>>> thoughts.
>>>
>>> For example, you have a C/C++ DLL which provides some business functions
>>> and you want to use them to implement SCA components.
>>>
>>> As the first step, you can even use implementation.java to call JNI
>>> and you
>>> just have to write an implementation class like:
>>>
>>> @Service(Calculator.class)
>>> public class JNICalculatorImpl implements Calculator {
>>> static {
>>> System.loadLibrary("calculator.dll");
>>> }
>>> public native int method calculate(String op, int n1, int n2);
>>>
>>> @Reference
>>> public Add addService;
>>> }
>>>
>>> And configure the component as:
>>>
>>> <component name="JNICalculatorComponent">
>>> <implementation.java class="calculator.dll"/>
>>> </component>
>>
>>
>> Did you mean ...
>>
>> <implementation.java class="JNICalculatorImpl "/>
>>
>
> Yes, that's what I meant. Thank you for correcting it.
>
>>
>>>
>>> For the second step, we can try to automate the JNI access as follows:
>>>
>>> 1) Model the component as implementation.jni:
>>>
>>> <component name="JNICalculatorComponent">
>>> <implementation.jni library="calculator.dll"/>
>>> </component>
>>>
>>> You also need to provide a componentType file to describe the JNI
>>> operations (Potentially we can introspect the native C++ interface).
>>>
>>> <componentType>
>>> <service name="Calculator">
>>> <interface.java interface="calculator.Calculator"/> <!-- This
>>> is the
>>> java interface for the JNI functions -->
>>> </service>
>>> <reference name="Add">
>>> <interface.java interface="calculator.Add"/> <!-- This is the java
>>> interface for the JNI functions -->
>>> </service>
>>> </componentType>
>>>
>>> Then we can generate the JNICalculatorImpl class as illustrated above to
>>> represent the JNI component using ASM.
>>
>>
>> This looks like a promising and straightforward idea to get dlls
>> working as
>> component implementations. In the native runtime there is a Java
>> scagen tool
>> that does C++ header file introspection. Its for generating C++ service
>> proxy classes but there may be some code that is of use there if there
>> is a
>> requirement to do instropection in this case
>>
>
> It would be great if we can introspect the C++ header file to create a
> componentType for the C++ components.
>
>>
>>
>>>
>>> Thanks,
>>> Raymond
>>>
>>> --------------------------------------------------
>>> From: ""Dietrich, Björn"" <B....@cenit.de>
>>> Sent: Wednesday, June 25, 2008 11:45 PM
>>> To: <us...@tuscany.apache.org>
>>> Subject: AW: Apache Tuscany doubts
>>>
>>>
>>> Hi,
>>>>
>>>> We are also looking for native (JNI) binding between Java and C++,
>>>> This would be a real cool feature.
>>>>
>>>> Greetings
>>>> Björn
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Malte Marquarding [mailto:malte.marquarding@gmail.com]
>>>> Gesendet: Donnerstag, 26. Juni 2008 02:51
>>>> An: user@tuscany.apache.org
>>>> Betreff: Re: Apache Tuscany doubts
>>>>
>>>> Hi,
>>>>
>>>> Is there a timeline for the java runtime hosting a c++ component? We
>>>> are
>>>> currently evaluating tuscany and need to access c++ components as
>>>> these are
>>>> needed for specialized algorithms.
>>>>
>>>>
>>>> Cheers,
>>>> Malte.
>>>>
>>>>
>>>> At this point, Tuscany has both Java and C++ for 1). But the java
>>>>> runtime doesn't support C++ component, and not C++ runtime supports
>>>>> Java component either. So we have to use different runtimes to host
>>>>> the C++ and Java components at this point, but it's potentially
>>>>> possible that the Java runtime will be capable of hosting C++
>>>>> component.
>>>>>
>>>>>
>>>>
>>>> CENIT AG Systemhaus, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49
>>>> 711 7825-30, Fax: +49 711 7825-4000, Internet: www.cenit.de
>>>> Geschaeftsstellen: Berlin, Duesseldorf, Frankfurt, Hamburg, Hannover,
>>>> Muenchen, Saarbruecken
>>>> Vorstandsmitglieder: Kurt Bengel, Christian Pusch
>>>> Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des
>>>> Aufsichtsrats),
>>>> Hubert Leypoldt, Andreas Karrer
>>>> Bankverbindungen:
>>>> Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166
>>>> 1040 00 SWIFT-CODE : DEUTDESS,
>>>> Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071
>>>> 0532
>>>> 0155 00 SWIFT-Code : COBADEFF600,
>>>> BW-Bank (BLZ 600 501 01) Kto. 2 403 313 IBAN : DE17 6005 0101 0002
>>>> 4033 13
>>>> SWIFT-Code : SOLADEST
>>>> Registergericht: Amtsgericht Stuttgart
>>>> Handelsregister: HRB Nr. 19117
>>>> Umsatzsteuer: ID-Nr. DE 147 862 777
>>>>
>>>>
>>
>
Re: JNI-based C/C++ component implementation for SCA: was: Re: AW:
Apache Tuscany doubts
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi, Simon.
>
> Please see my comments inline.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Simon Laws" <si...@googlemail.com>
> Sent: Friday, June 27, 2008 5:15 AM
> To: <us...@tuscany.apache.org>
> Subject: Re: AW: Apache Tuscany doubts
>
>> Hi Raymond
>>
>> Nice idea. Comments in line...
>>
>> If we did want to fully support C++ classes as SCA components, i.e. with
>> references and all the trimings then we could look to use the native
>> runtime
>> in the same domain, as opposed to in the same VM. Embedding it might be
>> tricky.
>
> Yes. There are two SCA runtimes in Tuscany, one is implemented in Java
> and the other in C++. But it should also be possible for the Java
> runtime to host C/C++ components and vice versa.
>
>>
>> Simon
>>
>> On Thu, Jun 26, 2008 at 7:16 PM, Raymond Feng <en...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Can you describe the use cases you have in mind? It will help us better
>>> understand what you want to achieve.
>>>
>>> Are you interested in contributing in this area? I can give some
>>> pointers
>>> and thoughts to get you started. The following is based on my
>>> on-the-surface
>>> thoughts.
>>>
>>> For example, you have a C/C++ DLL which provides some business functions
>>> and you want to use them to implement SCA components.
>>>
>>> As the first step, you can even use implementation.java to call JNI
>>> and you
>>> just have to write an implementation class like:
>>>
>>> @Service(Calculator.class)
>>> public class JNICalculatorImpl implements Calculator {
>>> static {
>>> System.loadLibrary("calculator.dll");
>>> }
>>> public native int method calculate(String op, int n1, int n2);
>>>
>>> @Reference
>>> public Add addService;
>>> }
>>>
>>> And configure the component as:
>>>
>>> <component name="JNICalculatorComponent">
>>> <implementation.java class="calculator.dll"/>
>>> </component>
>>
>>
>> Did you mean ...
>>
>> <implementation.java class="JNICalculatorImpl "/>
>>
>
> Yes, that's what I meant. Thank you for correcting it.
>
>>
>>>
>>> For the second step, we can try to automate the JNI access as follows:
>>>
>>> 1) Model the component as implementation.jni:
>>>
>>> <component name="JNICalculatorComponent">
>>> <implementation.jni library="calculator.dll"/>
>>> </component>
>>>
>>> You also need to provide a componentType file to describe the JNI
>>> operations (Potentially we can introspect the native C++ interface).
>>>
>>> <componentType>
>>> <service name="Calculator">
>>> <interface.java interface="calculator.Calculator"/> <!-- This
>>> is the
>>> java interface for the JNI functions -->
>>> </service>
>>> <reference name="Add">
>>> <interface.java interface="calculator.Add"/> <!-- This is the java
>>> interface for the JNI functions -->
>>> </service>
>>> </componentType>
>>>
>>> Then we can generate the JNICalculatorImpl class as illustrated above to
>>> represent the JNI component using ASM.
>>
>>
>> This looks like a promising and straightforward idea to get dlls
>> working as
>> component implementations. In the native runtime there is a Java
>> scagen tool
>> that does C++ header file introspection. Its for generating C++ service
>> proxy classes but there may be some code that is of use there if there
>> is a
>> requirement to do instropection in this case
>>
>
> It would be great if we can introspect the C++ header file to create a
> componentType for the C++ components.
>
>>
>>
>>>
>>> Thanks,
>>> Raymond
>>>
>>> --------------------------------------------------
>>> From: ""Dietrich, Björn"" <B....@cenit.de>
>>> Sent: Wednesday, June 25, 2008 11:45 PM
>>> To: <us...@tuscany.apache.org>
>>> Subject: AW: Apache Tuscany doubts
>>>
>>>
>>> Hi,
>>>>
>>>> We are also looking for native (JNI) binding between Java and C++,
>>>> This would be a real cool feature.
>>>>
>>>> Greetings
>>>> Björn
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Malte Marquarding [mailto:malte.marquarding@gmail.com]
>>>> Gesendet: Donnerstag, 26. Juni 2008 02:51
>>>> An: user@tuscany.apache.org
>>>> Betreff: Re: Apache Tuscany doubts
>>>>
>>>> Hi,
>>>>
>>>> Is there a timeline for the java runtime hosting a c++ component? We
>>>> are
>>>> currently evaluating tuscany and need to access c++ components as
>>>> these are
>>>> needed for specialized algorithms.
>>>>
>>>>
>>>> Cheers,
>>>> Malte.
>>>>
>>>>
>>>> At this point, Tuscany has both Java and C++ for 1). But the java
>>>>> runtime doesn't support C++ component, and not C++ runtime supports
>>>>> Java component either. So we have to use different runtimes to host
>>>>> the C++ and Java components at this point, but it's potentially
>>>>> possible that the Java runtime will be capable of hosting C++
>>>>> component.
>>>>>
>>>>>
Here are a few ideas:
a) Run your C++ component on the Tuscany C++ runtime, with an SCA Web
Service binding using Axis2C's mini-server or Apache Httpd. Run other
(Java?) components on the Java runtime. From the Java components use SCA
references wired to the C++ component using SCA Web Service bindings.
Note: The C++ runtime implements an older level of the SCA spec and
we've not tested much the interop with the Java runtime recently.
b) Use Raymond's JNI-based approach to run your C++ component on the
Java runtime.
c) Use approach (b) but run the C++ component in a different SCA node
(i.e. a different JVM) to shield your Java components from any side
effects caused by the C++ component of if you need to integrate several
C++ components with incompatible 3rd party dependencies for example.
Wiring components that run on different nodes/JVMs in an SCA domain is
very easy/transparent using the SCA default binding.
d) Options (b) or (c) with some level of integration to introspect the
C++ headers (to be developed), and generate the source of corresponding
Java interfaces or just their bytecode at runtime. This should be easy
to do by tweaking some of the generator code from the Tuscany C++ project.
Tell us what you think... We can probably brainstorm more and help find
the best integration approach if you tell us a little more about the
other kinds of components that you're integrating the C++ code with,
what kind of SCA support (like reference passing, use of SCA C++ APIs
etc) you're interested in (maybe not much if the C++ is existing code?),
and what kind of data (just simple types or complex objects?) you're
passing across.
Hope this helps.
--
Jean-Sebastien