On Tue, Jul 20, 2010 at 6:07 AM, Jean-Sebastien Delfino <[email protected]> wrote: > 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. >
Is there really no way you can try to do this in trunk? We have already got code to support dynamic interfaces in trunk, if it has bugs it would be vastly preferable to fix them in trunk than in a fork. I'd much prefer that we first try to fix up the dynamic interface support in trunk, at least initially, and only if/when we hit some issue that really is hard to fix without disrupting trunk then look at options like branches. ...ant
