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
