Jean-Sebastien Delfino wrote:
Hi all,
I'm starting to code a simple/minimalistic implementation.python
extension for Python components on the Java runtime, similar to what's
working on the native runtime [1].
It's really basic. Component business methods are written as Python
functions, references and properties are represented as Python function
objects and passed as function arguments, and JSON or XML structured
data are just represented as Python tuples.
I've started to write code for it this afternoon, and implementing it on
top of the Java runtime is looking easy so far. I'm planning to commit a
strawman in the next few days or next weekend, depending on how much
spare time I find to hack on this.
[1]
http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/samples/store-python/
Here's an update. I quickly ran into a number of issues and realized
that the Java runtime currently assumes the presence of Java business
interfaces and typed Java objects in a number of areas, and that working
with no Java at all (e.g just Python, or just BPEL) is not so easy at
the moment.
Here are a number of scenarios I've looked at:
- Atom binding flowing entries to a BPEL or Python scripting component
- JSON-RPC binding with a BPEL or scripting component
- a BPEL component and a scripting component wired together
- a scripting component not using a Java interface to type its service,
instead using a completely dynamic interface.
The first issue I've run into is that the latest JSON-RPC binding
implementation, based on jabsorb, only works if Java classes are
available for all the JSON compound types (on both service and reference
side) and components use Java interfaces (on the reference side in
particular, where the current code attempts to use the operation's Java
method! to initialize the jabsorb client...)
I'm not sure if anybody has tried to use the JSON-RPC binding with a
WSDL-typed component, but that's not working :)
So, I'm starting to experiment with, and really hack... the runtime,
some of the bindings and invokers, to explore what it would take to get
more dynamic components with no Java interfaces really working.
I may also have to tweak the databinding mediator which currently
assumes that the target of a mediation has pre-defined types for all its
arguments, which is not going to be the case for a dynamic operation.
I'm doing that in a sandbox 'dynamic' branch [1] for now as obviously my
hack changes are breaking changes not suitable for trunk, but I'll try
to update the group as I make some progress with this experiment.
Hope this helps.
[1] http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/dynamic/
--
Jean-Sebastien
