There's been talk in the past about removing the requirement for things like script and dynamic languages to require a .componentType side file to define the services, references and properties when they can't be introspected.
I'd really like to get support for this into the next release so have started having a go at it in r540132. Its a bit rough to start with so that anyone feels free to suggest or implement alternative approaches. I'm happy to rewrite it based on your comments or for others to help, at least now there's a couple of working testcases to show whats needed to be supported. The testcases where this is used are in modules\implementation-script\src\test\java\org\apache\tuscany\sca\implementation\script\itests\dynamic. The main changes are to include a dynamic field on the o.a.t.s.assemblyInterface and Operation which enable dynamic Interfaces and Operations to match any other Interface or Operation. One thing that isn't so good with the dynamic Operation is that it needs to keep track of which operation was called, so right now thats in a ThreadLocal, there must be something better, maybe having the operation name in the Message? Another change is the addition of a ComponentPreProcessor interface which implementations can implement so the assembly CompositeBuilder calls out to the implementation impl before wiring up the component. One thing I can't see how to easily support is a dynamic component having a reference wired to another dynamic component, as you need some sort of proxy object for the reference which has the possible methods on the proxy interface. I guess for languages which support something like a "no such method" function the proxy object could use that, but we'd need to be injecting some language specific proxy object supporting that for the reference. That would be a fun thing to look at if anyone is interested... ...ant