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
