In the new core2 API, component factory is no longer needed.
AtomicComponent contains the invocation chains and and is responsible
for creating invokers. Related to having WSDL or Java interface
types, one of the things we also did was separate proxy creation from
the wire so now you can invoke on RuntimeWire directly, while proxies
are created by a separate service. The presentation has some slides
on this that we didn't get to due to time constraints.
One issue that has come up is in both runtimes (core and core2) we
are using Method to represent invocations. This may cause issues
since a Java interface always has to be generated. One thing we could
look at is going to something more generic.
Jim
On Jun 21, 2006, at 2:07 AM, ant elder wrote:
+1
Where are you doing this and how can we start helping? A long time
ago I had
a go at something like this for the JavaScript component, the
interfaces it
had were along the lines of the ones below. probably a bit old now
with all
the other changes. One thing I found hard was having a nice way to
have
interfaces be either Java classes or WSDL portTypes particularly with
components invoking service references.
ComponentFactory {
Component createComponent(Component component);
}
Component {
ComponentDefinition getComponentDefinition();
Invoker createComponentInvoker(Map<String, Object> properties,
Map<String, Reference> references);
}
Invoker {
public Object invoke(String operationName, Object[] args);
}
ComponentDefinition {
Interface getInterface();
List<String> getReferenceNames();
List<Property> getProperties();
String getInitOperationName();
String getDestroyOperationName();
}
Property {
String getName();
Object getDefaultValue();
boolean isRequired();
}
Reference {
Interface getInterface();
Object getProxy();
Invoker getInvoker();
}
Interface {
}
ClassInterface {
class[] getInterfaceClasses();
}
WSDLInterface {
String getNamespce();
String getPortTypeName();
Definition getDefinition();
}
...ant
On 6/21/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
I'm trying to implement the sample ruby extension and running into
some
issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some
of the
code in the sandbox. I want to be able to implement my extension
class
without having to depend on base Tuscany runtime implementation
classes,
so I'm just implementing the SPI interfaces.
Unless I missed something (and it's very possible since I don't
understand all the pieces yet) here's what I found:
- with the code in the head, my AtomicComponentContext needs to
implement 15 methods;
- with the code in the sandbox, I have to implement 25 methods.
And this is just one class, I'm not even implementing the builders or
invokers yet... I think that in both cases this is too much.
It looks like the experiment in the sandbox is attempting to
provide a
simpler programming model for these extensions by hiding some of the
complexity in base implementation classes, but I think it will be
better
to define a set of independent interfaces and make some of them
optional. In other words if my extension does not wish to
implement one
of the interfaces, then it just doesn't need to, and the runtime
should
assume some default behavior, instead of forcing me to implement
all the
25 methods...
Another thought is to allow the contract to be implemented with
multiple
objects specialized in each aspect instead of one big object with 25
methods.
As I'm going through the implementation of the ruby component
implementation extension, I'm trying to come up with a short list of
requirements and methods that I think we really need to implement,
and
with that list I'd like us to prototype simpler SPI interfaces. If
anybody is interested in helping, please feel free to jump in, it
would
really be great if we could do a binding extension in parallel,
and also
if the people who actually developed some of the existing extensions
could come up with the requirements they've seen in terms of SPI and
proposals to improve our extensibility story.
Thanks,
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
