You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2010/06/28 04:37:33 UTC
Strawman implementation.python extension
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/
--
Jean-Sebastien
Re: Strawman implementation.python extension
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Giorgio Zoppi wrote:
> 2010/6/28 Jean-Sebastien Delfino <js...@apache.org>:
>> 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.
> Jean Sebastian, i looked at it a time ago as python entusiastic. And I
> found http://jepp.sourceforge.net/,
> which embeds cpython in a JVM. The licensing is free zlib/jpeg so it
> would help you
> to embed all the stuff using the speed of CPython, and it latest features.
>
> Just 1c,
> Giorgio.
>
Hi Giorgio,
I've started with Jython as I wanted to run in a pure-Java environment,
but it'll probably be possible to adapt the Java implementation
extension to native Python later if people want to try that out.
When I need to run native Python, right now I'm using the code in the
SCA native runtime project (see [1][2][3]).
[1]
http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/samples/store-python/
[2] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/python/
[3] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/modules/wsgi/
--
Jean-Sebastien
Re: Strawman implementation.python extension
Posted by Giorgio Zoppi <gi...@gmail.com>.
2010/6/28 Jean-Sebastien Delfino <js...@apache.org>:
> 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.
Jean Sebastian, i looked at it a time ago as python entusiastic. And I
found http://jepp.sourceforge.net/,
which embeds cpython in a JVM. The licensing is free zlib/jpeg so it
would help you
to embed all the stuff using the speed of CPython, and it latest features.
Just 1c,
Giorgio.
--
Quiero ser el rayo de sol que cada día te despierta
para hacerte respirar y vivir en me.
"Favola -Moda".
Re: Dynamic / java-less interface experiments, was: Strawman implementation.python
extension
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
> On Mon, Aug 23, 2010 at 6:15 PM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:>
>>>> - JSON-RPC binding not using the databinding framework
>>> I think we need to be careful about this....
>>>
>>> From a maintenance point of view it would be useful to follow the same
>>> infrastructure pattern regardless of what binding and implementation
>>> are in use. It may be possible to embody the notion of conversion to
>>> generic parameters into databinding itself.
>>>
>
> Could you please clarify what do you mean by JSON-RPC not using
> databinding framework. I'm pretty sure it is using the databinding
> framework. Did you mean JSONP by any chance ?
>
I really meant JSON-RPC.
In JSONRPCServiceServlet SVN r954414 (before my changes) [1], method
handleJSONRPCMethodInvocation() uses a jabsorb JSONArray to convert JSON
to an array of Java args and sets that Java array directly into the
invocation message body.
In JSONRPCClientInvoker SVN r988365 [2], method invoke() casts the
message body to an array of Java objects and passes it to a
jabsorb.Client proxy.
I also found another, unused, invoker implementation.
In JSONRPCBindingInvoker SVN r988365 [3], method invoke() casts the
message body to an array of Java objects and builds a JSONArray used to
produce the JSON-RPC request.
In these 3 instances:
- the JSON databinding is not used to (de)serialize the JSON stream;
- the jabsorb JSONArray and Client code require that the arg types be
defined as specific Java classes;
- the logic assumes that args are passed as elements of an Java array,
if the component uses an XML (or JSON) databinding for example that
doesn't work.
My changes only worked around these problems in the case I was
interested in.
I tweaked JSONRPCServiceServlet and JSONRPCBindingInvoker (as it was
closer to the expected logic than JSONRPCClient) to just pass the JSON
stream directly to/from the component if that component uses a JSON
databinding (as that's the databinding used in the Python component).
Fixing this completely would require more significant changes to the
JSON-RPC binding. For example if the component (say BPEL) expects
another databinding (XML DOM in the BPEL case) then the proper logic
would be to let the databinding framework perform the conversion from
JSON to XML DOM (but that goes a little over my head)... perhaps Raymond
or another databinding expert could help fix this...
[1]
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/binding-jsonrpc-runtime/src/main/java/org/apache/tuscany/sca/binding/jsonrpc/provider/JSONRPCServiceServlet.java?view=markup&pathrev=954414
[2]
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/binding-jsonrpc-runtime/src/main/java/org/apache/tuscany/sca/binding/jsonrpc/provider/JSONRPCClientInvoker.java?view=markup&pathrev=988365
[2]
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/binding-jsonrpc-runtime/src/main/java/org/apache/tuscany/sca/binding/jsonrpc/provider/JSONRPCBindingInvoker.java?view=markup&pathrev=988365
--
Jean-Sebastien
Re: Dynamic / java-less interface experiments, was: Strawman
implementation.python extension
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Aug 24, 2010 at 2:27 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Mon, Aug 23, 2010 at 6:15 PM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:>
>>>> - JSON-RPC binding not using the databinding framework
>>>
>>> I think we need to be careful about this....
>>>
>>> From a maintenance point of view it would be useful to follow the same
>>> infrastructure pattern regardless of what binding and implementation
>>> are in use. It may be possible to embody the notion of conversion to
>>> generic parameters into databinding itself.
>>>
>
> Could you please clarify what do you mean by JSON-RPC not using
> databinding framework. I'm pretty sure it is using the databinding
> framework. Did you mean JSONP by any chance ?
>
>>
>>> I'm +1 on further developing these changes in trunk at your
>>> convenience. There are interesting questions to answer here.
>>>
>>
>> OK, I've pushed some of the changes from sandbox to trunk and will try to
>> explore this further.
>>
>
> +1 to use trunk for further developing these changes. I'm particularly
> interested in couple of them.
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
This off topic but to point out why there may be some confusion. Under
TUSCANY-3635 I converted the JSONP binding to use the databinding
framework to investigate/solve an issue reported on the ML. This was
unrelated to any work that may be going on with JSONRPC.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Dynamic / java-less interface experiments, was: Strawman
implementation.python extension
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Aug 23, 2010 at 6:15 PM, Jean-Sebastien Delfino
<js...@apache.org> wrote:>
>>> - JSON-RPC binding not using the databinding framework
>>
>> I think we need to be careful about this....
>>
>> From a maintenance point of view it would be useful to follow the same
>> infrastructure pattern regardless of what binding and implementation
>> are in use. It may be possible to embody the notion of conversion to
>> generic parameters into databinding itself.
>>
Could you please clarify what do you mean by JSON-RPC not using
databinding framework. I'm pretty sure it is using the databinding
framework. Did you mean JSONP by any chance ?
>
>> I'm +1 on further developing these changes in trunk at your
>> convenience. There are interesting questions to answer here.
>>
>
> OK, I've pushed some of the changes from sandbox to trunk and will try to
> explore this further.
>
+1 to use trunk for further developing these changes. I'm particularly
interested in couple of them.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Dynamic / java-less interface experiments, was: Strawman implementation.python
extension
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> Hi
>
> ...snip
>
>> It'd be nice to get any technical comments on the issues I've started to
>> describe in this thread (I've seen no comments so far):
>> - assumption that there's a Java interface even for a dynamic service
>
> Just catching up....
>
> I have very cloudy memories of what was done for implementation.script
> re. dynamic interfaces. I just added an implementation.script sample
> to 2.x so I could play with it and remind myself. I just stole the
> calculator sample from 1.x but interestingly I was forced to add
> componentType files to describe the service interfaces using Java.
> This doesn't seem to be the case with 1.x so something a little odd
> there. Maybe I'm just wrong and the dynamic support was remove.
1.x also expected Java interfaces, for references at least, see method
createReferenceProxy in [1].
> Needless to say it confirms what you're saying that we rely on Java
> interfaces in this situation which seems onerous to the implementation
> developer with no interested in Java.
Right
>
> The assembly spec of course doesn't mandate any particular mechanism
> for deriving the component type of an implementation. It's up to each
> implementation. It does though say that we must be able to map service
> interfaces to WSDL1.1 in the case where remote interfaces must be
> compared for compatibility. This is tricky to do with any fidelity if
> we don't know what parameters/return types are required/provided by an
> operation through inspection. We need special code to force a match in
> the dynamic case.
>
> Looking at your changes it looks like you're approaching this by
> modeling a single dynamic operation on the service side...
>
> "default" service
> public String eval(String args) throws Exception;
This was just a hack to let the Java introspector build an interface
model from that instead of having to build the model by hand as I was
not sure about how to do it. I didn't intend to use that method as a
business operation.
> This could easily be converted to WSDL as is but doesn't say anything
> about what the contents of args is supposed to look like. I think your
> assuming a name/value list at the moment.
>
> It may be better for us to be a little more explicit in the case where
> a default (or dynamic) interface is required about how parameters are
> structured so that we can more easily cater for the generic case of
> interchangeable bindings and databindings. There are two cases I'm
> thinking about...
>
> 1/ when the user doesn't configure the binding with a contract. We
> have to generate a contact for the binding to work against, e.g. SMD
> or WSDL etc.
> 2/ when the user does configure the binding with a contract, as they
> can do with the ws binding. We have to be able to map between the
> binding contract and the implementation contract.
I had a simple view of this:
- if my script expects a fixed list of typed parameters, and I want to
tell my partner components and enforce that contract, I write that
contract in WSDL;
- if my script accepts anything, or I don't care about enforcing a
particular contract, I just write xsd:any in the WSDL, or I don't even
write it and the runtime builds that WSDL model with xsd:any for me.
> I'm not making a specific proposal. Am still are the thinking aloud stage.
Me too :)
>> - JSON-RPC binding not using the databinding framework
>
> I think we need to be careful about this....
>
> From a maintenance point of view it would be useful to follow the same
> infrastructure pattern regardless of what binding and implementation
> are in use. It may be possible to embody the notion of conversion to
> generic parameters into databinding itself.
>
>> - if anybody has tried WSDL-typed components with various bindings
>
> I suspect not. I've been looking at the normalization of contracts for
> comparison reasons. It's highlighted a few holes and we certainly need
> a matrix of tests that covers the various combinations. Needless to
> say we don't have this yet and it's required regardless of this
> exercise.
OK, I'll try to put together a WSDL-typed component with a few bindings.
>
>> - how the data-mediator should work in presence of dynamic operations
>
> Good question
>
...
> I'm +1 on further developing these changes in trunk at your
> convenience. There are interesting questions to answer here.
>
OK, I've pushed some of the changes from sandbox to trunk and will try
to explore this further.
[1]
http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/implementation-script/src/main/java/org/apache/tuscany/sca/implementation/script/ScriptInvokerFactory.java
--
Jean-Sebastien
Re: Dynamic / java-less interface experiments, was: Strawman
implementation.python extension
Posted by Simon Laws <si...@googlemail.com>.
Hi
...snip
>
> It'd be nice to get any technical comments on the issues I've started to
> describe in this thread (I've seen no comments so far):
> - assumption that there's a Java interface even for a dynamic service
Just catching up....
I have very cloudy memories of what was done for implementation.script
re. dynamic interfaces. I just added an implementation.script sample
to 2.x so I could play with it and remind myself. I just stole the
calculator sample from 1.x but interestingly I was forced to add
componentType files to describe the service interfaces using Java.
This doesn't seem to be the case with 1.x so something a little odd
there. Maybe I'm just wrong and the dynamic support was remove.
Needless to say it confirms what you're saying that we rely on Java
interfaces in this situation which seems onerous to the implementation
developer with no interested in Java.
The assembly spec of course doesn't mandate any particular mechanism
for deriving the component type of an implementation. It's up to each
implementation. It does though say that we must be able to map service
interfaces to WSDL1.1 in the case where remote interfaces must be
compared for compatibility. This is tricky to do with any fidelity if
we don't know what parameters/return types are required/provided by an
operation through inspection. We need special code to force a match in
the dynamic case.
Looking at your changes it looks like you're approaching this by
modeling a single dynamic operation on the service side...
"default" service
public String eval(String args) throws Exception;
This could easily be converted to WSDL as is but doesn't say anything
about what the contents of args is supposed to look like. I think your
assuming a name/value list at the moment.
It may be better for us to be a little more explicit in the case where
a default (or dynamic) interface is required about how parameters are
structured so that we can more easily cater for the generic case of
interchangeable bindings and databindings. There are two cases I'm
thinking about...
1/ when the user doesn't configure the binding with a contract. We
have to generate a contact for the binding to work against, e.g. SMD
or WSDL etc.
2/ when the user does configure the binding with a contract, as they
can do with the ws binding. We have to be able to map between the
binding contract and the implementation contract.
I'm not making a specific proposal. Am still are the thinking aloud stage.
> - JSON-RPC binding not using the databinding framework
I think we need to be careful about this....
>From a maintenance point of view it would be useful to follow the same
infrastructure pattern regardless of what binding and implementation
are in use. It may be possible to embody the notion of conversion to
generic parameters into databinding itself.
> - if anybody has tried WSDL-typed components with various bindings
I suspect not. I've been looking at the normalization of contracts for
comparison reasons. It's highlighted a few holes and we certainly need
a matrix of tests that covers the various combinations. Needless to
say we don't have this yet and it's required regardless of this
exercise.
> - how the data-mediator should work in presence of dynamic operations
Good question
>
>
> The following modules break for me (Ubuntu 9.10, OpenJDK 1.6.1 from the
> Ubuntu distro). This looks like a moving target, too. A few days ago module
> "Apache Tuscany SCA Specification Compliance Tests Java CI" was building OK,
> and IIRC I had one or two less failures in itests:
...snip
> Are others seeing the same build failures?
I was seeing a stack of failures on Monday but they seem to be mostly
under control now. I'm getting a clean build today. There are still
OASIS test failures which IMHO are a priority but I think if we keep
breaking the build then we're doing something wrong.
I'm +1 on further developing these changes in trunk at your
convenience. There are interesting questions to answer here.
> --
> Jean-Sebastien
>
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Dynamic / java-less interface experiments, was: Strawman implementation.python
extension
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Tue, Jul 20, 2010 at 6:07 AM, Jean-Sebastien Delfino
> <js...@apache.org> 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.
>
I don't see a problem with using a sandbox branch to experiment.
IMO a sandbox is a good way to show experimental work, without
disturbing the work in trunk as it looks like people are trying to fix
it and achieve OASIS compliance.
Also, it's really not easy to see if my experiments to enable a more
dynamic behavior are breaking something at this point, as I'm not able
to get a successful build even without my changes (see below).
On the other hand, the changes are in the sandbox for all to see now,
and if people are OK with these changes in trunk, I'll be happy to make
them there. Let me know... I'd like to hear from others too.
It'd be nice to get any technical comments on the issues I've started to
describe in this thread (I've seen no comments so far):
- assumption that there's a Java interface even for a dynamic service
- JSON-RPC binding not using the databinding framework
- if anybody has tried WSDL-typed components with various bindings
- how the data-mediator should work in presence of dynamic operations
The following modules break for me (Ubuntu 9.10, OpenJDK 1.6.1 from the
Ubuntu distro). This looks like a moving target, too. A few days ago
module "Apache Tuscany SCA Specification Compliance Tests Java CI" was
building OK, and IIRC I had one or two less failures in itests:
[INFO] Apache Tuscany SCA Tomcat Tribes Based EndPoint Registry FAILED
[3.146s]
[INFO] Apache Tuscany SCA Sample Helloworld BPEL ............. FAILED
[3.902s]
[INFO] Apache Tuscany SCA Sample Helloworld JAX-RS ........... FAILED
[1.229s]
[INFO] Apache Tuscany SCA Sample JMS HelloWorld in a WebApp .. FAILED
[2.374s]
[INFO] Apache Tuscany SCA Sample Helloworld Javascript Client FAILED
[1.173s]
[INFO] Apache Tuscany SCA Sample Helloworld JSP .............. FAILED
[0.812s]
[INFO] Apache Tuscany SCA Sample Helloworld using Stripes .... FAILED
[2.828s]
[INFO] Apache Tuscany SCA Sample Helloworld Servlet .......... FAILED
[0.511s]
[INFO] Apache Tuscany SCA Sample Launcher Embedded JSE ....... FAILED
[7.474s]
[INFO] Apache Tuscany SCA Sample Launcher Embedded OSGi ...... FAILED
[12.691s]
[INFO] Apache Tuscany SCA Sample Launcher Embedded OSGi using base jar
FAILED [5.598s]
[INFO] Apache Tuscany SCA iTest Distribution Legal Checks .... FAILED
[9.341s]
[INFO] Apache Tuscany SCA iTest Distribution Contribution binding-sca
Calculator FAILED [1.552s]
[INFO] Apache Tuscany SCA iTest Distribution Contribution binding-ws
Calculator FAILED [1.528s]
[INFO] Apache Tuscany SCA iTest Distribution Contribution binding-rmi
Calculator FAILED [1.241s]
[INFO] Apache Tuscany SCA iTest Distribution contribution
implementation-java Calculator FAILED [0.698s]
[INFO] Apache Tuscany SCA iTest Distribution Launcher Embedded JSE
FAILED [1.043s]
[INFO] Apache Tuscany SCA iTest Distribution Launcher Embedded OSGi
FAILED [0.676s]
[INFO] Apache Tuscany SCA iTest Nodes One JVM Using Tribes Registry
FAILED [4.981s]
[INFO] Apache Tuscany SCA iTest Nodes binding.sca Using Hazelcast
Registry FAILED [48.574s]
[INFO] Apache Tuscany SCA iTest Policies ..................... FAILED
[4.201s]
[INFO] Apache Tuscany SCA Specification Compliance Tests Assembly
FAILED [1:09.669s]
[INFO] Apache Tuscany SCA Specification Compliance Tests Java CI FAILED
[25.363s]
Are others seeing the same build failures?
--
Jean-Sebastien
Re: Dynamic / java-less interface experiments, was: Strawman
implementation.python extension
Posted by ant elder <an...@gmail.com>.
On Tue, Jul 20, 2010 at 6:07 AM, Jean-Sebastien Delfino
<js...@apache.org> 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
Dynamic / java-less interface experiments, was: Strawman implementation.python
extension
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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