Script components and script container in integration branch

[ant elder <an...@gmail.com>]

I've spent the weekend getting the script container going again, see the
code in [1], its looking pretty good now. I think we should eventually be
able to use this one container to support all the script language components
instead of having  separate containers for each language. Ideally script
components will be interchangeable between the C++ and Java runtimes, so
with that in mind i've started trying to use the various script samples from
the C++ runtime, so far thats the Python and Ruby calculator samples, now
copied into the script itests module. Currently there are some changes
required to get these running in the Java runtime and they are:

- Need a java Interface to invoke the sample from a test client
- Need to specify the full path of the script file - calculator/ on script
file resource
- Need to use a .componentType side file
- Ruby script @divideService variable needs to be changed to $divideService.
Whats the difference between the @ and $ characters in Ruby?
- Python components use a module attribute to define script file and the
attribute value doesn't include the .py suffix
- Python divide doesn't work with rounding as the line "result =
round(result)" fails as result is a string which seems a bit odd

Requiring the componentType side file seems the main problem, i'm going to
spend a bit of time now seeing if the java runtime can be made a bit more
dynamic like the C++ runtime to avoid needing these.

   ...ant

[1]
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/

Re: Script components and script container in integration branch

[ant elder <an...@gmail.com>]

Comments in line...

   ...ant

On 2/26/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> This looks pretty good to me. I have a few comments and questions inline.
>
> ant elder wrote:
> > I've spent the weekend getting the script container going again, see the
> > code in [1], its looking pretty good now. I think we should eventually
> be
> > able to use this one container to support all the script language
> > components
> > instead of having  separate containers for each language.
>
> With a single container, will there still be a way to customize the
> support for each language? For example in one language we may want to
> map references to instance variables in classes, while in another less
> object-oriented language we'll want to map them to global variables.
> Another example, one language may support interfaces, while another does
> have this concept at all. How will you provide different SCA programming
> models to these different scripting languages?


The generic BSF or JSR-223 APIs do try to deal with these language
differences, but using a generic API is going to be more limiting than using
specific languages engines directly, whether or not that matters depends on
the limitation and the language. If it is a problem for a particular
language then there are a number of options:
1) Having special case code in the generic container for the language.
There's already some cases of this, one dealing with Ruby class instances,
and another for the implementation.python syntax which the C++ runtime has
as different from the other languages.
2) If the Java engine for that language allows more flexibility than
provided by the BSF APIs then we could look at enhancing the BSF APIs. I've
just been voted a committer on that Apache project so this should be easy
enough to do now.
3) If all else fails implement a another separate container specifically for
that language. Though even then, there could be cases where the language
engine Java API just may not support all the function that the native
engines do. The Java APIs do seem a bit limited in some areas, eg OO script
languages.

What I've been doing so far is just adding tests for each bit of function in
each language and seeing what the problems are.

> Ideally script
> > components will be interchangeable between the C++ and Java runtimes, so
> > with that in mind i've started trying to use the various script
> > samples from
> > the C++ runtime, so far thats the Python and Ruby calculator samples,
> now
> > copied into the script itests module. Currently there are some changes
> > required to get these running in the Java runtime and they are:
> >
> > - Need a java Interface to invoke the sample from a test client
>
> Is it a limitation of the runtime?
>
Or is it a natural requirement anyway because your test client is
> written in Java?


Thats the SCA CompositeContext locateService method used by the itests which
requires an interface class. Maybe we could add a dynamic invocation API...

Can you write the test client as a script as well?


There are ways with some of the script language Java engines to get some
initialization to happen to add stuff to the script environment where we
could add in SCA/Tuscany, so that could probably be used to have some sort
of support for script language test clients.

We did at one point have a contribution from Jojo for an interactive
JavaScript client using Tuscany. I would like to look at getting that going
again one day, and it would be possible to do the same with other languages.
The interactive script clients are kind of cool allowing you to play around
with your SCA composites in an interactive way at a text console, which is
what Jojo's JavaScript client enabled. But its not exactly your killer app
is it :)

> - Need to specify the full path of the script file - calculator/ on
> > script
> > file resource


You didn't comment on that,  but hopefully the up-coming  contributions
service stuff will help.

> - Need to use a .componentType side file
> > - Ruby script @divideService variable needs to be changed to
> > $divideService.
> > Whats the difference between the @ and $ characters in Ruby?
>
> @variable is an instance variable
> $variable is a global variable


Yeah i found that out now. This seems like a BSF problem right now, may be a
case requiring one of those 3 options above but I'm still looking at it.

> - Python components use a module attribute to define script file and the
> > attribute value doesn't include the .py suffix
> > - Python divide doesn't work with rounding as the line "result =
> > round(result)" fails as result is a string which seems a bit odd
> >
> > Requiring the componentType side file seems the main problem, i'm
> > going to
> > spend a bit of time now seeing if the java runtime can be made a bit
> more
> > dynamic like the C++ runtime to avoid needing these.
> >
>
> You'll probably need to change the Java runtime a little to make
> interfaces optional.


Yes, I hope you're right about it just being a 'little' change :) I'd really
like to avoid having to use something like annotations in the scripts so
hopefully there are alternatives to annotations or .componentType files. The
SCA <service> and <reference> elements specify the interface so it may be
possible to get a script component to use the interface from there. If
there's a WSDL or Java interface with the same name as the script file we
could use that WSDL or class as the script interface. Properties don't seem
so hard at least for simple types.

Re: Script components and script container in integration branch

[Jean-Sebastien Delfino <js...@apache.org>]

This looks pretty good to me. I have a few comments and questions inline.

ant elder wrote:
> I've spent the weekend getting the script container going again, see the
> code in [1], its looking pretty good now. I think we should eventually be
> able to use this one container to support all the script language 
> components
> instead of having  separate containers for each language.

With a single container, will there still be a way to customize the 
support for each language? For example in one language we may want to 
map references to instance variables in classes, while in another less 
object-oriented language we'll want to map them to global variables. 
Another example, one language may support interfaces, while another does 
have this concept at all. How will you provide different SCA programming 
models to these different scripting languages?

> Ideally script
> components will be interchangeable between the C++ and Java runtimes, so
> with that in mind i've started trying to use the various script 
> samples from
> the C++ runtime, so far thats the Python and Ruby calculator samples, now
> copied into the script itests module. Currently there are some changes
> required to get these running in the Java runtime and they are:
>
> - Need a java Interface to invoke the sample from a test client

Is it a limitation of the runtime?
Or is it a natural requirement anyway because your test client is 
written in Java?
Can you write the test client as a script as well?

> - Need to specify the full path of the script file - calculator/ on 
> script
> file resource
> - Need to use a .componentType side file
> - Ruby script @divideService variable needs to be changed to 
> $divideService.
> Whats the difference between the @ and $ characters in Ruby?

@variable is an instance variable
$variable is a global variable

> - Python components use a module attribute to define script file and the
> attribute value doesn't include the .py suffix
> - Python divide doesn't work with rounding as the line "result =
> round(result)" fails as result is a string which seems a bit odd
>
> Requiring the componentType side file seems the main problem, i'm 
> going to
> spend a bit of time now seeing if the java runtime can be made a bit more
> dynamic like the C++ runtime to avoid needing these.
>

You'll probably need to change the Java runtime a little to make 
interfaces optional.

>   ...ant
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/ 
>
>

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org