You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Mohan, Mithun" <mm...@netapp.com> on 2008/06/06 19:04:12 UTC
Apache Tuscany doubts
Hello,
I am new to Apache Tuscany and it looks like a great tool . I am sort of
doing a project as an Intern .
I am trying to create a web service for sca components using Apache
Tuscany
I have a few doubts ,
1) Does Apache Tuscany take care of deploying the web-service or do we
need tools like Axis or CXF to deploy the web-service
As far as my understanding goes , in the home page of the Apache
Tuscany it takes care of making the web service online
http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+Web+
Services+with+Tuscany
2) Also, we have Apache Tuscany implemented in Java and also in C++ .
Is it possible to have SCA components in Java and C++ and stil exposed
as a single web service .
It will be great if anyone can spare some time and reply.
Thanks and Regards,
Mithun .
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
JNI-based C/C++ component implementation for SCA: was: Re: AW: Apache Tuscany doubts
Posted by Raymond Feng <en...@gmail.com>.
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: AW: Apache Tuscany doubts
Posted by Simon Laws <si...@googlemail.com>.
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.
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 "/>
>
> 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
>
> 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: AW: Apache Tuscany doubts
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jun 30, 2008 at 5:40 AM, Malte Marquarding <
malte.marquarding@gmail.com> wrote:
> Hi Simon,
>
> your mock up of operations looks pretty much like what I have myself.
> We are in the toddler stage of our project and looking into possible
> high-level architecture solutions. Traditionally astronomy is based on
> common frameworks ( e.g. CORBA). I tend to think that for scalability and
> to
> be able to re-use existing software in the various aspects of running the
> observations, a more heterogeneous approach as in SCA would be the better
> solution. So each component can select what implementation it suits best.
> Anyway I am looking into SOA/SCA in general and as we are interested in
> open
> source solutions naturally came across tuscany. I am interested in a bit
> more detailed discussion if you are available offline, because I really
> like
> to see us going forward with this. I can send you a whitepaper on our
> poject
> if you want.
>
> As to what is run on the supercomputer - as one of the solutions to
> workflow
> and load balancing we are looking into System S and doing some evaluation (
> I see you work for IBM so you might have heard of it ;-) ). So the native
> c++ components might not be necessary long term as System S also has a java
> API.
>
> Cheers,
> Malte.
>
>
> On Fri, Jun 27, 2008 at 11:18 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > On Fri, Jun 27, 2008 at 1:56 AM, Malte Marquarding <
> > malte.marquarding@gmail.com> wrote:
> >
> > > Hi Raymond,
> > >
> > > The system we envisage is roughly as follows.
> > >
> > > We are running a set of radio telescopes at remote site. The high level
> > > exposure of the various parts of system should be via service
> components.
> > > The actual implementation is specific to the problem.We have thl
> > telescope
> > > control (of the hardware). The data generated form these telescopes has
> > to
> > > be processed on a supercomputer ( hence implementation in c++), through
> a
> > > set of services like Calibration, Imaging, Analysis. It also has some
> > > control queue (running the end-to-end process, referencing the various
> > > services), archiving, logging, user access (virtual observatory)
> > components
> > > etc.
> > >
> > > I am investigating tuscany for this.
> > >
> > > Another unrelated problem I have is that I can't see (with SDOs and
> SCA
> > )
> > > how to handle the transfer of the data. The data output of the c++
> > services
> > > is tens to hundreds of Terabytes. I was thinking of having a DataMoving
> > > service encapsulating something like GridFTP. Has anyone got a
> suggestion
> > > of
> > > how to handle this in an SCA context.
> > >
> > > I can give more details if necessary.
> > >
> > > Cheers,
> > > Malte.
> > >
> > > On Fri, Jun 27, 2008 at 4:16 AM, 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.
> > > >
> > > >
> > >
> >
> > Hi Malte
> >
> > The bindings we have implemented to date are intended to operate in the
> > typical SOA environment where you pass data to a component and ask it to
> do
> > something. We tend to talk in terms of XML documents which will be fine
> for
> > the control messages you need but not suitable for the telescope data
> > itself.
> >
> > To try and understand the subtleties of your scenario I'm going to take
> the
> > components you suggested and invent some operations that we might expect
> to
> > find there...
> >
> > TelescopeControl
> > PerformObservation(ObservatonParameters, ObservationId)
> > // I assume you give the telescope a job to do, i.e point at the sky
> and
> > record the results against a given ID
> > // and then callback when the task is complete
> > DataTransfer
> > Transfer(FromLocation, ToLocation)
> > // just manages the task of moving large datasets across the network.
> As
> > you say gridFtp could be a candidate here.
> > Calibration
> > Run(ObservationId)
> > GetDatasetLocation(ID)
> > Imaging
> > Run(ObservationId)
> > GetDatasetLocation(ID)
> > Analysis
> > Run(ObservationId)
> > GetDatasetLocation(ID)
> > Archive
> > GetDatasetLocation(ID)
> > Logging
> > // are you logging control messages here
> > Coordination
> > DoSometing()
> > // coordinate the activities of the application, for example, it might
> do
> > TelescopeControl.PerformObservation(someParames, "reading1")
> > // when task is complete
> > fromLocation = TelescopeControl.GetDatasetLocation("reading1")
> > toLocation = Calibration.GetDatasetLocation("reading1")
> > DataTransfer.Transfer(fromLocation, toLocation)
> > Calibration.run("reading1")
> >
> > etc.
> >
> > The Calibration, Analysis, Imaging components are a bit tricky to
> > visualize.
> > Are they closely related or stand alone? Do they always have to run in
> > sequence in the same order? What sort of infrastructure do they rely on?
> > For
> > example, you mention a supercomputer so are we talking MPI collectives
> and
> > Condor like schedulers. In which case an SCA component such as
> "Calibrate"
> > may just wrap the task of creating and submitting JSDL to the scheduler
> > rather than representing the Calibration code itself. You may even
> resort
> > to a more generic "ComputeEngine" component that allows you to
> dynamically
> > configure jobs to be run.
> >
> > Personally I would like Tuscany to be able to slot right in here so that
> > the
> > analytical components could be supported in HPC environments with
> > appropriate SCA implementation types, bindings and integration with the
> > underlying HPC and grid infrastructure. We are not really there yet. I've
> > done some work on a LoadBalancer demo that shows Tuscany running in a
> > Tomcat
> > cluster but scenarios like yours can really help us all think what
> features
> > would be appropriate.
> >
> > Regards
> >
> > Simon
> >
>
Hi Malte
Sure, feel free to get me at my gmail address or on google talk.
Regards
Simon
Re: AW: Apache Tuscany doubts
Posted by Malte Marquarding <ma...@gmail.com>.
Hi Simon,
your mock up of operations looks pretty much like what I have myself.
We are in the toddler stage of our project and looking into possible
high-level architecture solutions. Traditionally astronomy is based on
common frameworks ( e.g. CORBA). I tend to think that for scalability and to
be able to re-use existing software in the various aspects of running the
observations, a more heterogeneous approach as in SCA would be the better
solution. So each component can select what implementation it suits best.
Anyway I am looking into SOA/SCA in general and as we are interested in open
source solutions naturally came across tuscany. I am interested in a bit
more detailed discussion if you are available offline, because I really like
to see us going forward with this. I can send you a whitepaper on our poject
if you want.
As to what is run on the supercomputer - as one of the solutions to workflow
and load balancing we are looking into System S and doing some evaluation (
I see you work for IBM so you might have heard of it ;-) ). So the native
c++ components might not be necessary long term as System S also has a java
API.
Cheers,
Malte.
On Fri, Jun 27, 2008 at 11:18 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Fri, Jun 27, 2008 at 1:56 AM, Malte Marquarding <
> malte.marquarding@gmail.com> wrote:
>
> > Hi Raymond,
> >
> > The system we envisage is roughly as follows.
> >
> > We are running a set of radio telescopes at remote site. The high level
> > exposure of the various parts of system should be via service components.
> > The actual implementation is specific to the problem.We have thl
> telescope
> > control (of the hardware). The data generated form these telescopes has
> to
> > be processed on a supercomputer ( hence implementation in c++), through a
> > set of services like Calibration, Imaging, Analysis. It also has some
> > control queue (running the end-to-end process, referencing the various
> > services), archiving, logging, user access (virtual observatory)
> components
> > etc.
> >
> > I am investigating tuscany for this.
> >
> > Another unrelated problem I have is that I can't see (with SDOs and SCA
> )
> > how to handle the transfer of the data. The data output of the c++
> services
> > is tens to hundreds of Terabytes. I was thinking of having a DataMoving
> > service encapsulating something like GridFTP. Has anyone got a suggestion
> > of
> > how to handle this in an SCA context.
> >
> > I can give more details if necessary.
> >
> > Cheers,
> > Malte.
> >
> > On Fri, Jun 27, 2008 at 4:16 AM, 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.
> > >
> > >
> >
>
> Hi Malte
>
> The bindings we have implemented to date are intended to operate in the
> typical SOA environment where you pass data to a component and ask it to do
> something. We tend to talk in terms of XML documents which will be fine for
> the control messages you need but not suitable for the telescope data
> itself.
>
> To try and understand the subtleties of your scenario I'm going to take the
> components you suggested and invent some operations that we might expect to
> find there...
>
> TelescopeControl
> PerformObservation(ObservatonParameters, ObservationId)
> // I assume you give the telescope a job to do, i.e point at the sky and
> record the results against a given ID
> // and then callback when the task is complete
> DataTransfer
> Transfer(FromLocation, ToLocation)
> // just manages the task of moving large datasets across the network. As
> you say gridFtp could be a candidate here.
> Calibration
> Run(ObservationId)
> GetDatasetLocation(ID)
> Imaging
> Run(ObservationId)
> GetDatasetLocation(ID)
> Analysis
> Run(ObservationId)
> GetDatasetLocation(ID)
> Archive
> GetDatasetLocation(ID)
> Logging
> // are you logging control messages here
> Coordination
> DoSometing()
> // coordinate the activities of the application, for example, it might do
> TelescopeControl.PerformObservation(someParames, "reading1")
> // when task is complete
> fromLocation = TelescopeControl.GetDatasetLocation("reading1")
> toLocation = Calibration.GetDatasetLocation("reading1")
> DataTransfer.Transfer(fromLocation, toLocation)
> Calibration.run("reading1")
>
> etc.
>
> The Calibration, Analysis, Imaging components are a bit tricky to
> visualize.
> Are they closely related or stand alone? Do they always have to run in
> sequence in the same order? What sort of infrastructure do they rely on?
> For
> example, you mention a supercomputer so are we talking MPI collectives and
> Condor like schedulers. In which case an SCA component such as "Calibrate"
> may just wrap the task of creating and submitting JSDL to the scheduler
> rather than representing the Calibration code itself. You may even resort
> to a more generic "ComputeEngine" component that allows you to dynamically
> configure jobs to be run.
>
> Personally I would like Tuscany to be able to slot right in here so that
> the
> analytical components could be supported in HPC environments with
> appropriate SCA implementation types, bindings and integration with the
> underlying HPC and grid infrastructure. We are not really there yet. I've
> done some work on a LoadBalancer demo that shows Tuscany running in a
> Tomcat
> cluster but scenarios like yours can really help us all think what features
> would be appropriate.
>
> Regards
>
> Simon
>
Re: AW: Apache Tuscany doubts
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jun 27, 2008 at 4:38 PM, Raymond Feng <en...@gmail.com> wrote:
> Thanks Simon for the quick and nice response. Just want to clarify a bit on
> the data transfer: In Tuscany SCA, the data can be in any format, XML or
> binary. What matters is the data formats that the communication protocol
> (binding) can handle. We also have a databinding framework to enable
> transparent data transformation across formats.
>
> For example, you can model the data transfer service as:
>
> DataTransfer
> byte[] receiveData(...);
> or
> InputStream receiveData();
> or
> Image receiveData();
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Simon Laws" <si...@googlemail.com>
> Sent: Friday, June 27, 2008 6:18 AM
> To: <us...@tuscany.apache.org>
> Subject: Re: AW: Apache Tuscany doubts
>
> On Fri, Jun 27, 2008 at 1:56 AM, Malte Marquarding <
>> malte.marquarding@gmail.com> wrote:
>>
>> Hi Raymond,
>>>
>>> The system we envisage is roughly as follows.
>>>
>>> We are running a set of radio telescopes at remote site. The high level
>>> exposure of the various parts of system should be via service components.
>>> The actual implementation is specific to the problem.We have thl
>>> telescope
>>> control (of the hardware). The data generated form these telescopes has
>>> to
>>> be processed on a supercomputer ( hence implementation in c++), through a
>>> set of services like Calibration, Imaging, Analysis. It also has some
>>> control queue (running the end-to-end process, referencing the various
>>> services), archiving, logging, user access (virtual observatory)
>>> components
>>> etc.
>>>
>>> I am investigating tuscany for this.
>>>
>>> Another unrelated problem I have is that I can't see (with SDOs and SCA
>>> )
>>> how to handle the transfer of the data. The data output of the c++
>>> services
>>> is tens to hundreds of Terabytes. I was thinking of having a DataMoving
>>> service encapsulating something like GridFTP. Has anyone got a suggestion
>>> of
>>> how to handle this in an SCA context.
>>>
>>> I can give more details if necessary.
>>>
>>> Cheers,
>>> Malte.
>>>
>>> On Fri, Jun 27, 2008 at 4:16 AM, 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.
>>> >
>>> >
>>>
>>>
>> Hi Malte
>>
>> The bindings we have implemented to date are intended to operate in the
>> typical SOA environment where you pass data to a component and ask it to
>> do
>> something. We tend to talk in terms of XML documents which will be fine
>> for
>> the control messages you need but not suitable for the telescope data
>> itself.
>>
>> To try and understand the subtleties of your scenario I'm going to take
>> the
>> components you suggested and invent some operations that we might expect
>> to
>> find there...
>>
>> TelescopeControl
>> PerformObservation(ObservatonParameters, ObservationId)
>> // I assume you give the telescope a job to do, i.e point at the sky and
>> record the results against a given ID
>> // and then callback when the task is complete
>> DataTransfer
>> Transfer(FromLocation, ToLocation)
>> // just manages the task of moving large datasets across the network. As
>> you say gridFtp could be a candidate here.
>> Calibration
>> Run(ObservationId)
>> GetDatasetLocation(ID)
>> Imaging
>> Run(ObservationId)
>> GetDatasetLocation(ID)
>> Analysis
>> Run(ObservationId)
>> GetDatasetLocation(ID)
>> Archive
>> GetDatasetLocation(ID)
>> Logging
>> // are you logging control messages here
>> Coordination
>> DoSometing()
>> // coordinate the activities of the application, for example, it might do
>> TelescopeControl.PerformObservation(someParames, "reading1")
>> // when task is complete
>> fromLocation = TelescopeControl.GetDatasetLocation("reading1")
>> toLocation = Calibration.GetDatasetLocation("reading1")
>> DataTransfer.Transfer(fromLocation, toLocation)
>> Calibration.run("reading1")
>>
>> etc.
>>
>> The Calibration, Analysis, Imaging components are a bit tricky to
>> visualize.
>> Are they closely related or stand alone? Do they always have to run in
>> sequence in the same order? What sort of infrastructure do they rely on?
>> For
>> example, you mention a supercomputer so are we talking MPI collectives and
>> Condor like schedulers. In which case an SCA component such as "Calibrate"
>> may just wrap the task of creating and submitting JSDL to the scheduler
>> rather than representing the Calibration code itself. You may even resort
>> to a more generic "ComputeEngine" component that allows you to dynamically
>> configure jobs to be run.
>>
>> Personally I would like Tuscany to be able to slot right in here so that
>> the
>> analytical components could be supported in HPC environments with
>> appropriate SCA implementation types, bindings and integration with the
>> underlying HPC and grid infrastructure. We are not really there yet. I've
>> done some work on a LoadBalancer demo that shows Tuscany running in a
>> Tomcat
>> cluster but scenarios like yours can really help us all think what
>> features
>> would be appropriate.
>>
>> Regards
>>
>> Simon
>>
>>
Hi Raymond
Yeah, I'm not saying that SCA components would never be at either end of the
data transfer but that we don't have the HPC type bindings to support this
at the moment. I was proposing that an incremental step would be to use a
service to orchestrate the data transfer, using a well known mechanism like
GFTP or UPS, and build our experience so that we can write a suitable
binding.
Assuming that we have a suitable high performance databinding in the future
the question is how to use it. I wasn't thinking that we would wire the
telescope to the anaylsis directly for data transport purposes as which
analysis and compute engine is chosen seems to be subject to external
process.Neither was I thinking of wiring the telescope to the analysis via
the controller component for data transfer puposes. Control messages yes but
not data transfer. Hence I was suggesting that a data transfer component
would control how the data is moved from the telescope to the compute
engine. In this later case you could imagine a CallableRerence being passed
to the compute engine so that it can pull down the required data form the
telescope. So I think the types of components that we have could remain
fairly constant but we could experiment with increasing the level of
Tuscany/SCA support as we learn more.
Thoughts?
Simon
Re: AW: Apache Tuscany doubts
Posted by Raymond Feng <en...@gmail.com>.
Thanks Simon for the quick and nice response. Just want to clarify a bit on
the data transfer: In Tuscany SCA, the data can be in any format, XML or
binary. What matters is the data formats that the communication protocol
(binding) can handle. We also have a databinding framework to enable
transparent data transformation across formats.
For example, you can model the data transfer service as:
DataTransfer
byte[] receiveData(...);
or
InputStream receiveData();
or
Image receiveData();
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Friday, June 27, 2008 6:18 AM
To: <us...@tuscany.apache.org>
Subject: Re: AW: Apache Tuscany doubts
> On Fri, Jun 27, 2008 at 1:56 AM, Malte Marquarding <
> malte.marquarding@gmail.com> wrote:
>
>> Hi Raymond,
>>
>> The system we envisage is roughly as follows.
>>
>> We are running a set of radio telescopes at remote site. The high level
>> exposure of the various parts of system should be via service components.
>> The actual implementation is specific to the problem.We have thl
>> telescope
>> control (of the hardware). The data generated form these telescopes has
>> to
>> be processed on a supercomputer ( hence implementation in c++), through a
>> set of services like Calibration, Imaging, Analysis. It also has some
>> control queue (running the end-to-end process, referencing the various
>> services), archiving, logging, user access (virtual observatory)
>> components
>> etc.
>>
>> I am investigating tuscany for this.
>>
>> Another unrelated problem I have is that I can't see (with SDOs and
>> SCA )
>> how to handle the transfer of the data. The data output of the c++
>> services
>> is tens to hundreds of Terabytes. I was thinking of having a DataMoving
>> service encapsulating something like GridFTP. Has anyone got a suggestion
>> of
>> how to handle this in an SCA context.
>>
>> I can give more details if necessary.
>>
>> Cheers,
>> Malte.
>>
>> On Fri, Jun 27, 2008 at 4:16 AM, 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.
>> >
>> >
>>
>
> Hi Malte
>
> The bindings we have implemented to date are intended to operate in the
> typical SOA environment where you pass data to a component and ask it to
> do
> something. We tend to talk in terms of XML documents which will be fine
> for
> the control messages you need but not suitable for the telescope data
> itself.
>
> To try and understand the subtleties of your scenario I'm going to take
> the
> components you suggested and invent some operations that we might expect
> to
> find there...
>
> TelescopeControl
> PerformObservation(ObservatonParameters, ObservationId)
> // I assume you give the telescope a job to do, i.e point at the sky
> and
> record the results against a given ID
> // and then callback when the task is complete
> DataTransfer
> Transfer(FromLocation, ToLocation)
> // just manages the task of moving large datasets across the network.
> As
> you say gridFtp could be a candidate here.
> Calibration
> Run(ObservationId)
> GetDatasetLocation(ID)
> Imaging
> Run(ObservationId)
> GetDatasetLocation(ID)
> Analysis
> Run(ObservationId)
> GetDatasetLocation(ID)
> Archive
> GetDatasetLocation(ID)
> Logging
> // are you logging control messages here
> Coordination
> DoSometing()
> // coordinate the activities of the application, for example, it might
> do
> TelescopeControl.PerformObservation(someParames, "reading1")
> // when task is complete
> fromLocation = TelescopeControl.GetDatasetLocation("reading1")
> toLocation = Calibration.GetDatasetLocation("reading1")
> DataTransfer.Transfer(fromLocation, toLocation)
> Calibration.run("reading1")
>
> etc.
>
> The Calibration, Analysis, Imaging components are a bit tricky to
> visualize.
> Are they closely related or stand alone? Do they always have to run in
> sequence in the same order? What sort of infrastructure do they rely on?
> For
> example, you mention a supercomputer so are we talking MPI collectives and
> Condor like schedulers. In which case an SCA component such as "Calibrate"
> may just wrap the task of creating and submitting JSDL to the scheduler
> rather than representing the Calibration code itself. You may even resort
> to a more generic "ComputeEngine" component that allows you to dynamically
> configure jobs to be run.
>
> Personally I would like Tuscany to be able to slot right in here so that
> the
> analytical components could be supported in HPC environments with
> appropriate SCA implementation types, bindings and integration with the
> underlying HPC and grid infrastructure. We are not really there yet. I've
> done some work on a LoadBalancer demo that shows Tuscany running in a
> Tomcat
> cluster but scenarios like yours can really help us all think what
> features
> would be appropriate.
>
> Regards
>
> Simon
>
Re: AW: Apache Tuscany doubts
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jun 27, 2008 at 1:56 AM, Malte Marquarding <
malte.marquarding@gmail.com> wrote:
> Hi Raymond,
>
> The system we envisage is roughly as follows.
>
> We are running a set of radio telescopes at remote site. The high level
> exposure of the various parts of system should be via service components.
> The actual implementation is specific to the problem.We have thl telescope
> control (of the hardware). The data generated form these telescopes has to
> be processed on a supercomputer ( hence implementation in c++), through a
> set of services like Calibration, Imaging, Analysis. It also has some
> control queue (running the end-to-end process, referencing the various
> services), archiving, logging, user access (virtual observatory) components
> etc.
>
> I am investigating tuscany for this.
>
> Another unrelated problem I have is that I can't see (with SDOs and SCA )
> how to handle the transfer of the data. The data output of the c++ services
> is tens to hundreds of Terabytes. I was thinking of having a DataMoving
> service encapsulating something like GridFTP. Has anyone got a suggestion
> of
> how to handle this in an SCA context.
>
> I can give more details if necessary.
>
> Cheers,
> Malte.
>
> On Fri, Jun 27, 2008 at 4:16 AM, 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.
> >
> >
>
Hi Malte
The bindings we have implemented to date are intended to operate in the
typical SOA environment where you pass data to a component and ask it to do
something. We tend to talk in terms of XML documents which will be fine for
the control messages you need but not suitable for the telescope data
itself.
To try and understand the subtleties of your scenario I'm going to take the
components you suggested and invent some operations that we might expect to
find there...
TelescopeControl
PerformObservation(ObservatonParameters, ObservationId)
// I assume you give the telescope a job to do, i.e point at the sky and
record the results against a given ID
// and then callback when the task is complete
DataTransfer
Transfer(FromLocation, ToLocation)
// just manages the task of moving large datasets across the network. As
you say gridFtp could be a candidate here.
Calibration
Run(ObservationId)
GetDatasetLocation(ID)
Imaging
Run(ObservationId)
GetDatasetLocation(ID)
Analysis
Run(ObservationId)
GetDatasetLocation(ID)
Archive
GetDatasetLocation(ID)
Logging
// are you logging control messages here
Coordination
DoSometing()
// coordinate the activities of the application, for example, it might do
TelescopeControl.PerformObservation(someParames, "reading1")
// when task is complete
fromLocation = TelescopeControl.GetDatasetLocation("reading1")
toLocation = Calibration.GetDatasetLocation("reading1")
DataTransfer.Transfer(fromLocation, toLocation)
Calibration.run("reading1")
etc.
The Calibration, Analysis, Imaging components are a bit tricky to visualize.
Are they closely related or stand alone? Do they always have to run in
sequence in the same order? What sort of infrastructure do they rely on? For
example, you mention a supercomputer so are we talking MPI collectives and
Condor like schedulers. In which case an SCA component such as "Calibrate"
may just wrap the task of creating and submitting JSDL to the scheduler
rather than representing the Calibration code itself. You may even resort
to a more generic "ComputeEngine" component that allows you to dynamically
configure jobs to be run.
Personally I would like Tuscany to be able to slot right in here so that the
analytical components could be supported in HPC environments with
appropriate SCA implementation types, bindings and integration with the
underlying HPC and grid infrastructure. We are not really there yet. I've
done some work on a LoadBalancer demo that shows Tuscany running in a Tomcat
cluster but scenarios like yours can really help us all think what features
would be appropriate.
Regards
Simon
Re: AW: Apache Tuscany doubts
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Malte Marquarding wrote:
> Hi Raymond,
>
> The system we envisage is roughly as follows.
>
> We are running a set of radio telescopes at remote site. The high level
> exposure of the various parts of system should be via service components.
> The actual implementation is specific to the problem.We have thl telescope
> control (of the hardware). The data generated form these telescopes has to
> be processed on a supercomputer ( hence implementation in c++), through a
> set of services like Calibration, Imaging, Analysis. It also has some
> control queue (running the end-to-end process, referencing the various
> services), archiving, logging, user access (virtual observatory) components
> etc.
>
> I am investigating tuscany for this.
>
...
I've just finished reading that thread (as I was away on vacation) and
I'm going to expand the scope of the discussion a little, to see if we
can find the best architecture with SCA for your application :)
What technologies can you run on your supercomputer? just C++ code? or
can you also run Java code (the Tuscany Java runtime for example)?
Does it run Apache Httpd by any chance?
The Tuscany C++ code currently builds on Windows, Linux, Mac-OS. Do you
think that a Linux build (the typical automake build) will work on your
computer?
What protocols are currently available to provide access to your C++
services? any chance you already have support for SOAP Web Services?
Corba? anything else?
--
Jean-Sebastien
Re: AW: Apache Tuscany doubts
Posted by Malte Marquarding <ma...@gmail.com>.
Hi Raymond,
The system we envisage is roughly as follows.
We are running a set of radio telescopes at remote site. The high level
exposure of the various parts of system should be via service components.
The actual implementation is specific to the problem.We have thl telescope
control (of the hardware). The data generated form these telescopes has to
be processed on a supercomputer ( hence implementation in c++), through a
set of services like Calibration, Imaging, Analysis. It also has some
control queue (running the end-to-end process, referencing the various
services), archiving, logging, user access (virtual observatory) components
etc.
I am investigating tuscany for this.
Another unrelated problem I have is that I can't see (with SDOs and SCA )
how to handle the transfer of the data. The data output of the c++ services
is tens to hundreds of Terabytes. I was thinking of having a DataMoving
service encapsulating something like GridFTP. Has anyone got a suggestion of
how to handle this in an SCA context.
I can give more details if necessary.
Cheers,
Malte.
On Fri, Jun 27, 2008 at 4:16 AM, 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.
>
>
Re: AW: Apache Tuscany doubts
Posted by Raymond Feng <en...@gmail.com>.
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>
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.
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: AW: Apache Tuscany doubts
Posted by "Balasubramanyam, Shivakumar" <sb...@qualcomm.com>.
With the conformance to SDO, Either shared memory or sockets would be the least effort.
-----Original Message-----
From: velian / Daniel Rogowski [mailto:d.rogowski@velian.de]
Sent: Thursday, June 26, 2008 10:45 AM
To: user@tuscany.apache.org
Subject: Re: AW: Apache Tuscany doubts
Dietrich, Björn schrieb:
> We are also looking for native (JNI) binding between Java and C++,
> This would be a real cool feature.
Did you try Jace (http://sourceforge.net/projects/jace/)?
I think such a feature has nothing to do with SCA. I've lots of JNI
experience and imho it's not the best possbile "binding" between C++-
and Java-Components. It's very error prone, even with Jace.
Best Regards
Daniel Rogowski
--
velian GmbH IT-Solutions, Software & Consulting
Daniel Rogowski - Leiter der Softwareentwicklung
- Chief Development Officer (CDO)
Rebenring 33, 38106 Braunschweig
Telefon: +49 531 3804 310
Telefax: +49 531 3804 152
Mobil: +49 163 4606 352
http://www.velian.de
Ust.-ID: DE 256368411
Amtsgericht Braunschweig, HRB 200992 | Geschäftsführer: Michael Körber
Re: AW: Apache Tuscany doubts
Posted by velian / Daniel Rogowski <d....@velian.de>.
Dietrich, Björn schrieb:
> We are also looking for native (JNI) binding between Java and C++,
> This would be a real cool feature.
Did you try Jace (http://sourceforge.net/projects/jace/)?
I think such a feature has nothing to do with SCA. I've lots of JNI
experience and imho it's not the best possbile "binding" between C++-
and Java-Components. It's very error prone, even with Jace.
Best Regards
Daniel Rogowski
--
velian GmbH IT-Solutions, Software & Consulting
Daniel Rogowski - Leiter der Softwareentwicklung
- Chief Development Officer (CDO)
Rebenring 33, 38106 Braunschweig
Telefon: +49 531 3804 310
Telefax: +49 531 3804 152
Mobil: +49 163 4606 352
http://www.velian.de
Ust.-ID: DE 256368411
Amtsgericht Braunschweig, HRB 200992 | Geschäftsführer: Michael Körber
AW: Apache Tuscany doubts
Posted by "Dietrich, Björn" <B....@cenit.de>.
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: Apache Tuscany doubts
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jun 26, 2008 at 8:17 AM, haleh mahbod <hm...@gmail.com> wrote:
> Can we have a composite that contains a C++ component running on SCA C++
> and a Java component running on SCA Java? I think this used to work at some
> point. Just confirming.
>
>
> On 6/25/08, Malte Marquarding <ma...@gmail.com> wrote:
> >
> > 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.
> > >
> >
>
We can't have a composite that mixes C++ and Java implementations. We could
have two composites, one with a C++ component and the other with a Java
component, in and SCA domain and then have the C++ runtime run the C++
composite and the Java runtime run the Java composite. The automatic domain
support we have doesn't currently integrate with the C++ runtime but this
solution could be created manually I expect.
Simon
Re: Apache Tuscany doubts
Posted by haleh mahbod <hm...@gmail.com>.
Can we have a composite that contains a C++ component running on SCA C++
and a Java component running on SCA Java? I think this used to work at some
point. Just confirming.
On 6/25/08, Malte Marquarding <ma...@gmail.com> wrote:
>
> 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.
> >
>
Re: Apache Tuscany doubts
Posted by Malte Marquarding <ma...@gmail.com>.
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.
>
Re: Apache Tuscany doubts
Posted by Raymond Feng <en...@gmail.com>.
Hi, Sorry for the late response. It skipped out of my eyes.
Please see my comments inline.
Thanks,
Raymnd
--------------------------------------------------
From: "Mohan, Mithun" <mm...@netapp.com>
Sent: Friday, June 06, 2008 11:08 AM
To: <tu...@ws.apache.org>
Subject: RE: Apache Tuscany doubts
>
>
> Raymond wrote---
> Yes, Tuscany makes the Web Service available once you have a component
> with "binding.ws" service binding configured. In the J2SE environment,
> it should be registered with an embedded HTTP server such as Jetty or
> Tomcat and use
> Axis2 stack underneath to handle the WS invocations. If it's deployed
> with a web container such as Tomcat, we use the Servlet filter to trap
> the Web Services traffic.
> -----------------------
>
> So does that mean I need to use an server like Tomcat or Tuscany takes
> care of it ? I did not quite understand the meaning of deployed with a
> web container.I am able to just compile the composite file to get the
> output . I am not able to deploy this composite file as a web service.
>
There are different ways to deploy and run a Tuscany SCA composite
application. For example, if you package it as a web application following
the pattern described at
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Web+Application+based+Integration+with+Geronimo,
and deploy it to a Tomcat server, then Tomcat will bootstrap the webapp and
the WS will be made available.
If you run it as a J2SE application, then you can follow the sample at
http://svn.apache.org/repos/asf/tuscany/java/sca/samples/helloworld-ws-service/src/main/java/helloworld/HelloWorldServer.java.
You need to have either embedded Tomcat or Jetty on the classpath.
>
>
>
> Raymond wrote---
> There are two concepts:
> 1) A SCA runtime (or container) written in Java or C++
> 2) A SCA component written in Java or C++
> 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.
> ---------------------------
>
> So now say for eg I have two components one implemented in java and the
> other implemented in C++.So if I was planning to make this a web service
> .
>
> 1) Do I need to have separate composite files and then merge it to a
> single web service
> 2) Do I have common composite file ?
>
SCA components provide services and consume services. SCA services can be
exposed as Web Services. You have two components (one implemented in Java
and the other in C++), what does the composition of these two components
look like? There could be one composite file or two composite files,
depending on how you compose the components.
> It will be great if someone replies my doubts
>
> Thanks and Regards,
> Mithun
>
>
>
>
>
> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Friday, June 06, 2008 1:45 PM
> To: tuscany-user@ws.apache.org
> Subject: Re: Apache Tuscany doubts
>
> Thank you for your interests in Tuscany. Please see my comments inline.
>
> Raymond
>
> --------------------------------------------------
> From: "Mohan, Mithun" <mm...@netapp.com>
> Sent: Friday, June 06, 2008 10:04 AM
> To: <tu...@ws.apache.org>
> Cc: <lr...@apache.org>
> Subject: Apache Tuscany doubts
>
>> Hello,
>>
>> I am new to Apache Tuscany and it looks like a great tool . I am sort
>> of doing a project as an Intern .
>> I am trying to create a web service for sca components using Apache
>> Tuscany I have a few doubts ,
>>
>> 1) Does Apache Tuscany take care of deploying the web-service or do we
>
>> need tools like Axis or CXF to deploy the web-service
>> As far as my understanding goes , in the home page of the Apache
>> Tuscany it takes care of making the web service online
>> http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+We
>> b+
>> Services+with+Tuscany
>>
>
> Yes, Tuscany makes the Web Service available once you have a component
> with "binding.ws" service binding configured. In the J2SE environment,
> it should be registered with an embedded HTTP server such as Jetty or
> Tomcat and use
> Axis2 stack underneath to handle the WS invocations. If it's deployed
> with a web container such as Tomcat, we use the Servlet filter to trap
> the Web Services traffic.
>
>> 2) Also, we have Apache Tuscany implemented in Java and also in C++ .
>> Is it possible to have SCA components in Java and C++ and stil exposed
>
>> as a single web service .
>
> There are two concepts:
> 1) A SCA runtime (or container) written in Java or C++
> 2) A SCA component written in Java or C++
>
> 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.
>>
>> It will be great if anyone can spare some time and reply.
>>
>> Thanks and Regards,
>> Mithun .
>>
RE: Apache Tuscany doubts
Posted by "Mohan, Mithun" <mm...@netapp.com>.
Raymond wrote---
Yes, Tuscany makes the Web Service available once you have a component
with "binding.ws" service binding configured. In the J2SE environment,
it should be registered with an embedded HTTP server such as Jetty or
Tomcat and use
Axis2 stack underneath to handle the WS invocations. If it's deployed
with a web container such as Tomcat, we use the Servlet filter to trap
the Web Services traffic.
-----------------------
So does that mean I need to use an server like Tomcat or Tuscany takes
care of it ? I did not quite understand the meaning of deployed with a
web container.I am able to just compile the composite file to get the
output . I am not able to deploy this composite file as a web service.
Raymond wrote---
There are two concepts:
1) A SCA runtime (or container) written in Java or C++
2) A SCA component written in Java or C++
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.
---------------------------
So now say for eg I have two components one implemented in java and the
other implemented in C++.So if I was planning to make this a web service
.
1) Do I need to have separate composite files and then merge it to a
single web service
2) Do I have common composite file ?
It will be great if someone replies my doubts
Thanks and Regards,
Mithun
-----Original Message-----
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Friday, June 06, 2008 1:45 PM
To: tuscany-user@ws.apache.org
Subject: Re: Apache Tuscany doubts
Thank you for your interests in Tuscany. Please see my comments inline.
Raymond
--------------------------------------------------
From: "Mohan, Mithun" <mm...@netapp.com>
Sent: Friday, June 06, 2008 10:04 AM
To: <tu...@ws.apache.org>
Cc: <lr...@apache.org>
Subject: Apache Tuscany doubts
> Hello,
>
> I am new to Apache Tuscany and it looks like a great tool . I am sort
> of doing a project as an Intern .
> I am trying to create a web service for sca components using Apache
> Tuscany I have a few doubts ,
>
> 1) Does Apache Tuscany take care of deploying the web-service or do we
> need tools like Axis or CXF to deploy the web-service
> As far as my understanding goes , in the home page of the Apache
> Tuscany it takes care of making the web service online
> http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+We
> b+
> Services+with+Tuscany
>
Yes, Tuscany makes the Web Service available once you have a component
with "binding.ws" service binding configured. In the J2SE environment,
it should be registered with an embedded HTTP server such as Jetty or
Tomcat and use
Axis2 stack underneath to handle the WS invocations. If it's deployed
with a web container such as Tomcat, we use the Servlet filter to trap
the Web Services traffic.
> 2) Also, we have Apache Tuscany implemented in Java and also in C++ .
> Is it possible to have SCA components in Java and C++ and stil exposed
> as a single web service .
There are two concepts:
1) A SCA runtime (or container) written in Java or C++
2) A SCA component written in Java or C++
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.
>
> It will be great if anyone can spare some time and reply.
>
> Thanks and Regards,
> Mithun .
>
Re: Apache Tuscany doubts
Posted by Raymond Feng <en...@gmail.com>.
Thank you for your interests in Tuscany. Please see my comments inline.
Raymond
--------------------------------------------------
From: "Mohan, Mithun" <mm...@netapp.com>
Sent: Friday, June 06, 2008 10:04 AM
To: <tu...@ws.apache.org>
Cc: <lr...@apache.org>
Subject: Apache Tuscany doubts
> Hello,
>
> I am new to Apache Tuscany and it looks like a great tool . I am sort of
> doing a project as an Intern .
> I am trying to create a web service for sca components using Apache
> Tuscany
> I have a few doubts ,
>
> 1) Does Apache Tuscany take care of deploying the web-service or do we
> need tools like Axis or CXF to deploy the web-service
> As far as my understanding goes , in the home page of the Apache
> Tuscany it takes care of making the web service online
> http://cwiki.apache.org/confluence/display/TUSCANY/Build+your+first+Web+
> Services+with+Tuscany
>
Yes, Tuscany makes the Web Service available once you have a component with
"binding.ws" service binding configured. In the J2SE environment, it should
be registered with an embedded HTTP server such as Jetty or Tomcat and use
Axis2 stack underneath to handle the WS invocations. If it's deployed with a
web container such as Tomcat, we use the Servlet filter to trap the Web
Services traffic.
> 2) Also, we have Apache Tuscany implemented in Java and also in C++ .
> Is it possible to have SCA components in Java and C++ and stil exposed
> as a single web service .
There are two concepts:
1) A SCA runtime (or container) written in Java or C++
2) A SCA component written in Java or C++
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.
>
> It will be great if anyone can spare some time and reply.
>
> Thanks and Regards,
> Mithun .
>