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 2006/06/21 10:37:58 UTC
Tuscany SPI interfaces
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jim Marino <jm...@myromatours.com>.
Why do you need to implement an interface as opposed to extend an
abstract class when most of the methods are simple getters/setter
pairs? This is a very common pattern in found in Servlets, Struts,
WebWork, Srping and Hibernate, to name just a few. It allows people
to progressively buy into an extension API, picking up complexity as
needed.
If one wants maximum control, I still think things are very simple,
and this is exactly why I don't like counting methods without going
through what they are intended to do:
public class FooAllAtomicComponent implements AtomicComponent<Object> {
public boolean isEagerInit() {
return false;
}
public void init(Object instance) throws TargetException {
}
public void destroy(Object instance) throws TargetException {
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public List<Class<?>> getServiceInterfaces() {
return null;
}
public void addInboundWire(InboundWire wire) {
}
public InboundWire getInboundWire(String serviceName) {
return null;
}
public void addOutboundWire(OutboundWire wire) {
}
public void addOutboundWires(Class<?> multiplicityClass,
List<OutboundWire> wires) {
}
public Map<String, List<OutboundWire>> getOutboundWires() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method operation) {
return null;
}
public String getName() {
return null;
}
public CompositeComponent getParent() {
return null;
}
public Scope getScope() {
return null;
}
public Object getServiceInstance() throws TargetException {
return null;
}
public void prepare() {
}
public void publish(Event object) {
}
public void addListener(RuntimeEventListener listener) {
}
public void addListener(EventFilter filter, RuntimeEventListener
listener) {
}
public void removeListener(RuntimeEventListener listener) {
}
public int getLifecycleState() {
return 0;
}
public void start() throws CoreRuntimeException {
}
public void stop() throws CoreRuntimeException {
}
Going in order:
- init/destroy initialize and destroy an instance
- createInstance(), getServiceInstance(String name)
getServiceInterfaces(), createTargetInvoker() are the same as before
- addInboundWire(InboundWire wire) adds an inbound wire to the
component
- addOutboundWire(OutboundWire wire), addOutboundWires(Class<?>
multiplicityClass, List<OutboundWire> wires) provide the outbound
wires to the component
- getOutboundWires() returns the outbound wire
- getName() returns the component name
- getParent() returns the composite parent
- getScope() returns the component scope
- getServiceInstance() returns a default service instance
- prepare() is a callback to signal that the component has been
configured and should "prepare" itself to receive invocations
- publish(Event object), addListener(RuntimeEventListener
listener), addListener(EventFilter filter, RuntimeEventListener
listener), removeListener(RuntimeEventListener listener) provide
listener services particularly useful to composites
- getLifecycleState() returns the state of the component, e.g.
initializing, etc.
- start() and stop() are callbacks issued by the runtime
All of these methods deal directly with a component and are very easy
to implement. I don't see the need to Balkanize the API. Which of
these methods do you think can be broken out?
Jim
On Jun 21, 2006, at 2:08 AM, Jean-Sebastien Delfino wrote:
> Jim Marino wrote:
>> I think you missed something. With core2, most people will extend
>> from the helper abstract classes in the SPI extension package
>> (this was also the case with the previous core). For example:
>
> I didn't miss this class, as I said that's exactly what I'm trying
> to avoid. I want to implement the SPI interfaces without having to
> extend base implementation classes.
>
>>
>> public class FooAtomicComponent extends
>> AtomicComponentExtension<Object>{
>>
>> public FooAtomicComponent(String name, CompositeComponent<?>
>> parent, ScopeContainer scopeContainer, WireService wireService) {
>> super(name, parent, scopeContainer, wireService);
>> }
>>
>> public Object getServiceInstance() throws TargetException {
>> return null;
>> }
>>
>> public Object createInstance() throws ObjectCreationException {
>> return null;
>> }
>>
>> public Object getServiceInstance(String name) throws
>> TargetException {
>> return null;
>> }
>>
>> public List<Class<?>> getServiceInterfaces() {
>> return null;
>> }
>>
>> public TargetInvoker createTargetInvoker(String serviceName,
>> Method operation) {
>> return null;
>> }
>> }
>>
>> I generally don't like to "count" methods without looking at what
>> they do (e.g. some could just be setter/getter types). The above
>> class contains 5 methods, which I believe are reasonable and we
>> don't want to separate out. Invoker is very simple too:
>>
>> - Two methods to invoke, one for "message" invocations, and one
>> for raw payloads. Generally, the first will just pull the payload
>> and invoke the second
>> - A setter/getter pair for whether the invocation is cacheable
>> - A boolean if the invoker can be optimized away and the target
>> can be called through straight invocation without a proxy.
>> Generally false.
>> - A clone method
>>
>> The Spring and Groovy samples in the sandbox demonstrate both of
>> these.
>>
>> Jim
>>
>>
>>
>> On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jeremy Boynes <jb...@apache.org>.
Raymond Feng wrote:
> Hi, Jeremy.
>
> Thanks for the clarification.
>
> For the SDO loader, I have posted a patch before (
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03792.html ).
> Please review and apply.
>
Thanks - I remember the type scoping discussion that followed and forgot
the patch. I'll look at this later today.
> Thank you for bringing up the issue on how we support more flexible
> loader registrations. There are some potential use cases:
>
> 1) Register a loader by one or more element QNames (In the SDO loader
> impl, a QName for now is required to create a loader instance for the
> given element)
I think we can do this now by providing your own init method or
overriding start() and stop() in LoaderExtension - you just need to call
register multiple times. Would that work or did you mean something else?
> 2) Register a loader by one or more type QNames
We had talked about extending the Loader contract to support types (I'll
see if that is in the patch you referred to above). I think the current
approach would work for this as well - seem reasonable?
Once we do this I would suggest we also rename StAXElementLoader to
StAXLoader (as it will be able to handle more than just elements).
> 3) Register a loader by one or more namespaces
> 4) Register a loader by wildcards against QNames
>
I'd like to discuss these a little more in conjunction with the
extensibility story for SDO itself. I can see the value in SDO but this
may be overkill for SCA.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Raymond Feng <en...@gmail.com>.
Hi, Jeremy.
Thanks for the clarification.
For the SDO loader, I have posted a patch before (
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03792.html ).
Please review and apply.
Thank you for bringing up the issue on how we support more flexible loader
registrations. There are some potential use cases:
1) Register a loader by one or more element QNames (In the SDO loader impl,
a QName for now is required to create a loader instance for the given
element)
2) Register a loader by one or more type QNames
3) Register a loader by one or more namespaces
4) Register a loader by wildcards against QNames
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, June 21, 2006 3:03 PM
Subject: Re: Tuscany SPI interfaces
> Raymond Feng wrote:
>> Hi,
>>
>> I guess one of the concerns is that some of the base classes create
>> additional contracts which are not captured by the interfaces. It ends
>> up that the extension developers have to understand more.
>>
>
> I agree that that would be a concern. That wasn't the intention here.
> The intention was that the base classes would aid the extension
> developer by providing default implementations of parts of the contract
> that would be common to typical extensions.
>
> The contracts should be fully defined by the interfaces; the extensions
> just happen to provide common implementations.
>
>> Let's use the "StAXElementLoader" and "LoaderExtension" as an example.
>> Interface StAXElementLoader only requires the "load" method to be
>> implemented while "LoaderExtension" defines a contract on how a
>> StAXElementLoader register/deregister with the LoaderRegistry.
>
> Not quite - there is a bi-directional contract between the
> LoaderRegistry and each StAXElementLoader. Implementations of
> StAXElementLoader register with a loader implementation using the
> LoaderRegistry interface; in turn the loader implementation calls back
> to registered StAXElementLoader implementations to handle an element in
> a XML stream.
>
> The contract is fully defined by the StAXElementLoader and
> LoaderRegistry interfaces. LoaderExtension does not add anything to
> that, it just provides a default implementation of a registration
> mechanism.
>
>> This is achieved by java annotations.
>
> The way the default works is by using the lifecycle model from the SCA
> specification. It starts with the assumption that the extension will be
> provided as a composite. When the composite starts, the spec says that
> all components inside it designated as "eager-init" are automatically
> started. When a Java implementation is started, its "init" method must
> be called. Currently the only way an "init" method can be specified is
> via an @Init annotation; that's really an omission from the spec - there
> should be a way to specify that in the componentType sidefile as well.
>
> LoaderExtension uses this mechanism to register the component with the
> LoaderRegistry. As a provider, you just create your loader component as
> a subclass of LoaderExtension and include it in your composite - when
> the composite is started the init method is called and you automatically
> get registered with the LoaderRegistry; when your composite stops you
> are automatically unregistered.
>
> Of course, you don't have to use that. You can register a
> StAXElementLoader with the LoaderRegistry at any time just by calling
> its register method. The bootstrap code does this to register the
> primordial set of loaders.
>
> This ties back to the goals we had at the top. The contract here is
> specified in the SPI interfaces (LoaderRegistry and StAXElementLoader);
> the LoaderExtension base class provides a default implementation based
> on the SCA lifecycle model but it is just a default - you can register
> in any way supported by the LoaderRegistry contract.
>
>>
>> For this particular case, I can see two ways to get an extension picked
>> up by the runtime: declarative or programmatic. Some further questions
>> will be:
>>
>> 1) Should the extension developers have a choice to use either java
>> annotations or external XML configuration?
>>
>
> They should - the spec does not have mechanism to represent lifecycle in
> XML and that's a problem with the spec. That would be a good proposal to
> put forward.
>
>> 2) Should the extension metadata (for example, the XML element name that
>> a loader can handle) be captured in a model and java annotation is just
>> a convenient way to supply the value?
>>
>
> When a loader registers it explicitly specifies the element it wants to
> handle (it can actually register multiple times). This is part of the
> LoaderRegistry contract.
>
> The default implementation in LoaderExtension gets that from the
> sub-class by calling the getXMLType() abstract method. How that method
> determines the type is up to the extension developer. The
> implementations we have now just return the QName as that seemed really
> simple and they are typically specialized to handle one element.
> However, how they actually do it is down to them. It certainly would be
> possible for a more generic implementation to load it from a resource,
> an annotation, having it be injected as a SCA Property value, by parsing
> some other XML config file and so on.
>
> For example, I know you were working on a loader implementation that
> used SDO. Once you know the set of elements you want SDO to handle you
> would just need to register your loader with the LoaderRegistry for each
> of them. You probably would not want to use LoaderExtension at all.
>
> If I can help get this SDO loader integrated, please let me know (if you
> have posted a patch and I've forgotten please send me a pointer to it).
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jeremy Boynes <jb...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I guess one of the concerns is that some of the base classes create
> additional contracts which are not captured by the interfaces. It ends
> up that the extension developers have to understand more.
>
I agree that that would be a concern. That wasn't the intention here.
The intention was that the base classes would aid the extension
developer by providing default implementations of parts of the contract
that would be common to typical extensions.
The contracts should be fully defined by the interfaces; the extensions
just happen to provide common implementations.
> Let's use the "StAXElementLoader" and "LoaderExtension" as an example.
> Interface StAXElementLoader only requires the "load" method to be
> implemented while "LoaderExtension" defines a contract on how a
> StAXElementLoader register/deregister with the LoaderRegistry.
Not quite - there is a bi-directional contract between the
LoaderRegistry and each StAXElementLoader. Implementations of
StAXElementLoader register with a loader implementation using the
LoaderRegistry interface; in turn the loader implementation calls back
to registered StAXElementLoader implementations to handle an element in
a XML stream.
The contract is fully defined by the StAXElementLoader and
LoaderRegistry interfaces. LoaderExtension does not add anything to
that, it just provides a default implementation of a registration mechanism.
> This is achieved by java annotations.
The way the default works is by using the lifecycle model from the SCA
specification. It starts with the assumption that the extension will be
provided as a composite. When the composite starts, the spec says that
all components inside it designated as "eager-init" are automatically
started. When a Java implementation is started, its "init" method must
be called. Currently the only way an "init" method can be specified is
via an @Init annotation; that's really an omission from the spec - there
should be a way to specify that in the componentType sidefile as well.
LoaderExtension uses this mechanism to register the component with the
LoaderRegistry. As a provider, you just create your loader component as
a subclass of LoaderExtension and include it in your composite - when
the composite is started the init method is called and you automatically
get registered with the LoaderRegistry; when your composite stops you
are automatically unregistered.
Of course, you don't have to use that. You can register a
StAXElementLoader with the LoaderRegistry at any time just by calling
its register method. The bootstrap code does this to register the
primordial set of loaders.
This ties back to the goals we had at the top. The contract here is
specified in the SPI interfaces (LoaderRegistry and StAXElementLoader);
the LoaderExtension base class provides a default implementation based
on the SCA lifecycle model but it is just a default - you can register
in any way supported by the LoaderRegistry contract.
>
> For this particular case, I can see two ways to get an extension picked
> up by the runtime: declarative or programmatic. Some further questions
> will be:
>
> 1) Should the extension developers have a choice to use either java
> annotations or external XML configuration?
>
They should - the spec does not have mechanism to represent lifecycle in
XML and that's a problem with the spec. That would be a good proposal to
put forward.
> 2) Should the extension metadata (for example, the XML element name that
> a loader can handle) be captured in a model and java annotation is just
> a convenient way to supply the value?
>
When a loader registers it explicitly specifies the element it wants to
handle (it can actually register multiple times). This is part of the
LoaderRegistry contract.
The default implementation in LoaderExtension gets that from the
sub-class by calling the getXMLType() abstract method. How that method
determines the type is up to the extension developer. The
implementations we have now just return the QName as that seemed really
simple and they are typically specialized to handle one element.
However, how they actually do it is down to them. It certainly would be
possible for a more generic implementation to load it from a resource,
an annotation, having it be injected as a SCA Property value, by parsing
some other XML config file and so on.
For example, I know you were working on a loader implementation that
used SDO. Once you know the set of elements you want SDO to handle you
would just need to register your loader with the LoaderRegistry for each
of them. You probably would not want to use LoaderExtension at all.
If I can help get this SDO loader integrated, please let me know (if you
have posted a patch and I've forgotten please send me a pointer to it).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jim Marino <jm...@myromatours.com>.
On Jun 21, 2006, at 1:30 PM, Raymond Feng wrote:
> Hi,
>
> I guess one of the concerns is that some of the base classes create
> additional contracts which are not captured by the interfaces. It
> ends up that the extension developers have to understand more.
>
Actually, I think they have to understand less. Using the base
classes, they do not need to worry about how to register and
deregister the loaders. Do you feel the loader extensions are too
complicated? If so, what would an easier one look like?
> Let's use the "StAXElementLoader" and "LoaderExtension" as an
> example. Interface StAXElementLoader only requires the "load"
> method to be implemented while "LoaderExtension" defines a contract
> on how a StAXElementLoader register/deregister with the
> LoaderRegistry. This is achieved by java annotations.
>
> For this particular case, I can see two ways to get an extension
> picked up by the runtime: declarative or programmatic. Some further
> questions will be:
>
> 1) Should the extension developers have a choice to use either java
> annotations or external XML configuration?
>
> 2) Should the extension metadata (for example, the XML element name
> that a loader can handle) be captured in a model and java
> annotation is just a convenient way to supply the value?
>
We had decided the system service model would be based on annotations
a while back. I'm happy to revisit but I don't see any value in
allowing for external configuration of *component type* data. This is
also consistent with the SCA programming model which views external
component type metadata for Java C&I POJOs to be primarily for
"legacy code".
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, June 21, 2006 2:08 AM
> Subject: Re: Tuscany SPI interfaces
>
>
>> Jim Marino wrote:
>>> I think you missed something. With core2, most people will extend
>>> from the helper abstract classes in the SPI extension package
>>> (this was also the case with the previous core). For example:
>>
>> I didn't miss this class, as I said that's exactly what I'm trying
>> to avoid. I want to implement the SPI interfaces without having to
>> extend base implementation classes.
>>
>>>
>>> public class FooAtomicComponent extends
>>> AtomicComponentExtension<Object>{
>>>
>>> public FooAtomicComponent(String name, CompositeComponent<?>
>>> parent, ScopeContainer scopeContainer, WireService wireService) {
>>> super(name, parent, scopeContainer, wireService);
>>> }
>>>
>>> public Object getServiceInstance() throws TargetException {
>>> return null;
>>> }
>>>
>>> public Object createInstance() throws ObjectCreationException {
>>> return null;
>>> }
>>>
>>> public Object getServiceInstance(String name) throws
>>> TargetException {
>>> return null;
>>> }
>>>
>>> public List<Class<?>> getServiceInterfaces() {
>>> return null;
>>> }
>>>
>>> public TargetInvoker createTargetInvoker(String serviceName,
>>> Method operation) {
>>> return null;
>>> }
>>> }
>>>
>>> I generally don't like to "count" methods without looking at what
>>> they do (e.g. some could just be setter/getter types). The above
>>> class contains 5 methods, which I believe are reasonable and we
>>> don't want to separate out. Invoker is very simple too:
>>>
>>> - Two methods to invoke, one for "message" invocations, and one
>>> for raw payloads. Generally, the first will just pull the payload
>>> and invoke the second
>>> - A setter/getter pair for whether the invocation is cacheable
>>> - A boolean if the invoker can be optimized away and the target
>>> can be called through straight invocation without a proxy.
>>> Generally false.
>>> - A clone method
>>>
>>> The Spring and Groovy samples in the sandbox demonstrate both of
>>> these.
>>>
>>> Jim
>>>
>>>
>>>
>>> On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino 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: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I guess one of the concerns is that some of the base classes create
additional contracts which are not captured by the interfaces. It ends up
that the extension developers have to understand more.
Let's use the "StAXElementLoader" and "LoaderExtension" as an example.
Interface StAXElementLoader only requires the "load" method to be
implemented while "LoaderExtension" defines a contract on how a
StAXElementLoader register/deregister with the LoaderRegistry. This is
achieved by java annotations.
For this particular case, I can see two ways to get an extension picked up
by the runtime: declarative or programmatic. Some further questions will be:
1) Should the extension developers have a choice to use either java
annotations or external XML configuration?
2) Should the extension metadata (for example, the XML element name that a
loader can handle) be captured in a model and java annotation is just a
convenient way to supply the value?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, June 21, 2006 2:08 AM
Subject: Re: Tuscany SPI interfaces
> Jim Marino wrote:
>> I think you missed something. With core2, most people will extend from
>> the helper abstract classes in the SPI extension package (this was also
>> the case with the previous core). For example:
>
> I didn't miss this class, as I said that's exactly what I'm trying to
> avoid. I want to implement the SPI interfaces without having to extend
> base implementation classes.
>
>>
>> public class FooAtomicComponent extends AtomicComponentExtension<Object>{
>>
>> public FooAtomicComponent(String name, CompositeComponent<?> parent,
>> ScopeContainer scopeContainer, WireService wireService) {
>> super(name, parent, scopeContainer, wireService);
>> }
>>
>> public Object getServiceInstance() throws TargetException {
>> return null;
>> }
>>
>> public Object createInstance() throws ObjectCreationException {
>> return null;
>> }
>>
>> public Object getServiceInstance(String name) throws TargetException
>> {
>> return null;
>> }
>>
>> public List<Class<?>> getServiceInterfaces() {
>> return null;
>> }
>>
>> public TargetInvoker createTargetInvoker(String serviceName, Method
>> operation) {
>> return null;
>> }
>> }
>>
>> I generally don't like to "count" methods without looking at what they do
>> (e.g. some could just be setter/getter types). The above class contains 5
>> methods, which I believe are reasonable and we don't want to separate
>> out. Invoker is very simple too:
>>
>> - Two methods to invoke, one for "message" invocations, and one for raw
>> payloads. Generally, the first will just pull the payload and invoke the
>> second
>> - A setter/getter pair for whether the invocation is cacheable
>> - A boolean if the invoker can be optimized away and the target can be
>> called through straight invocation without a proxy. Generally false.
>> - A clone method
>>
>> The Spring and Groovy samples in the sandbox demonstrate both of these.
>>
>> Jim
>>
>>
>>
>> On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
> I think you missed something. With core2, most people will extend from
> the helper abstract classes in the SPI extension package (this was
> also the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying to
avoid. I want to implement the SPI interfaces without having to extend
base implementation classes.
>
> public class FooAtomicComponent extends AtomicComponentExtension<Object>{
>
> public FooAtomicComponent(String name, CompositeComponent<?>
> parent, ScopeContainer scopeContainer, WireService wireService) {
> super(name, parent, scopeContainer, wireService);
> }
>
> public Object getServiceInstance() throws TargetException {
> return null;
> }
>
> public Object createInstance() throws ObjectCreationException {
> return null;
> }
>
> public Object getServiceInstance(String name) throws
> TargetException {
> return null;
> }
>
> public List<Class<?>> getServiceInterfaces() {
> return null;
> }
>
> public TargetInvoker createTargetInvoker(String serviceName,
> Method operation) {
> return null;
> }
> }
>
> I generally don't like to "count" methods without looking at what they
> do (e.g. some could just be setter/getter types). The above class
> contains 5 methods, which I believe are reasonable and we don't want
> to separate out. Invoker is very simple too:
>
> - Two methods to invoke, one for "message" invocations, and one for
> raw payloads. Generally, the first will just pull the payload and
> invoke the second
> - A setter/getter pair for whether the invocation is cacheable
> - A boolean if the invoker can be optimized away and the target can be
> called through straight invocation without a proxy. Generally false.
> - A clone method
>
> The Spring and Groovy samples in the sandbox demonstrate both of these.
>
> Jim
>
>
>
> On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jim Marino <jm...@myromatours.com>.
I think you missed something. With core2, most people will extend
from the helper abstract classes in the SPI extension package (this
was also the case with the previous core). For example:
public class FooAtomicComponent extends
AtomicComponentExtension<Object>{
public FooAtomicComponent(String name, CompositeComponent<?>
parent, ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public List<Class<?>> getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method operation) {
return null;
}
}
I generally don't like to "count" methods without looking at what
they do (e.g. some could just be setter/getter types). The above
class contains 5 methods, which I believe are reasonable and we don't
want to separate out. Invoker is very simple too:
- Two methods to invoke, one for "message" invocations, and one for
raw payloads. Generally, the first will just pull the payload and
invoke the second
- A setter/getter pair for whether the invocation is cacheable
- A boolean if the invoker can be optimized away and the target can
be called through straight invocation without a proxy. Generally false.
- A clone method
The Spring and Groovy samples in the sandbox demonstrate both of these.
Jim
On Jun 21, 2006, at 1:37 AM, Jean-Sebastien Delfino 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jim Marino <jm...@myromatours.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Modeling interface definitions, was: Tuscany SPI interfaces
Posted by ant elder <an...@gmail.com>.
Comments inline, hope its not becoming hard to read.
...ant
On 6/22/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Jun 22, 2006, at 2:00 AM, ant elder wrote:
>
> > I've come across difficulties related to this in the work I've done
> > with
> > extensions:
> >
> > - I tried adding another interface type a while back in M1 to have an
> > interface.smd to support the Dojo Simple Method Description for the
> > AJAX
> > binding (http://dojo.jot.com/SMD). I couldn't get it to work as the
> > current
> > code really didn't seem to be designed to support additional interface
> > types.
> >
> > - Another problem already touched on here and earlier in this
> > thread by Jim
> > is that right now the logical representation is a Java interfaces and
> > java.lang.Method is used to represent invocations. Because of this
> > I've not
> > yet been able to get a component to be able to call a reference using
> > non-Java parameters, eg the JavaScript component invoking a
> > reference using
> > E4X objects. (there's a testcase trying to do this in the rhino
> > container in
> > my sandbox if you're interested in more details)
> >
> O.K. I'll take a look but it may take a few days as I'm supposed to
> be on vacation but still have a backlog of work to take care of too.
> Quick questions:
>
> - You are talking about E4XServiceRefsTestCase?
Yes
- HelloWorldProxyImpl flows an invoke to HelloWorldComponent2b which
> is another JavaScript component but the intent/point is the target
> can be anything?
Component HelloWorldComponentE4XProxy has impl
tests/HelloWorldE4XProxyImpl.js which is wired to component
HelloWorldComponentE4X which has impl tests/e4x.js and
tests/e4x.js uses interface.wsdl in its .componentType side file. Right now
to use E4X objects the interface must be a WSDL interface.
-An interceptor is interposed in the invocation to handle data
> transformation (in this case it could be optimized away since it is a
> js-->js invoke)?
Yes. Not sure the interceptor is the right approach, I just tried this as i
couldn't get the other way to work (see below)
- Is SDO needed in the interceptor or is that something you just used
> for expediency to do a conversion?
Just for expediency. Its the only databinding code we have right now that
can transform XML bytes into typed Java Objects. (
org.apache.tuscany.databinding.sdo.SDOXMLHelper)
This is going to bring up some interesting questions regarding
> policy. I'm wondering if the target invoker should be doing the
> transformation as opposed to an interceptor and the target invoker
> could just use the data transformation service Raymond was working
> on?
Yes. I did try that approach with the M1 extension SPIs but without
rewriting/duplicating a Iot of code I couldn't get at enough of the config
to be able to setup the SDO databinding correctly. Eg, from somewhere like
JavaScriptContextFactoryBuilder or JavaScriptContextFactory it needs to be
able to see there is reference which has a WSDLServiceContract and get at
the WSDL Definition. This is partly because right now it only works with E4X
parameters when the service or reference is typed with a WSDL portType (
interface.wsdl). That seemed like an ok restriction to me at the time.
An interesting issue is if that is the case (or even if we have
> an interceptor do the transformation), how do we deal with a policy
> interceptor or handler that operates on the body of the messages?
> Raymond, would this be a two step process?
>
Is it possible in Rhino to take an E4X object and pass it by
> reference to a JS target? In SCA, we assume pass-by-ref semantics
> within a shared memory space and it would be cool if we could
> optimize this. Also, it would be interesting if we could do pass-by-
> reference from Javascript to Java somehow (e.g. does E4X maintain
> some type of backing XML representation that could be passed)?
The actual JavaScript/E4X Rhino object is a
org.mozilla.javascript.xml.XMLObject. Thats backed by an XmlBeans
org.apache.xmlbeans.XmlObject. I guess ideally JS to JS would pass the
XMLObject, but in the JS to Java case it could pass it either the XmlObject
or use some databinding to convert the XML to a Java representation.
> - Also related to this is the message format, transformation and
> > multiple
> > databinding support thats being discussed in other threads and
> > JIRAs. Should
> > a component or binding be able to put whatever type of object it
> > likes into
> > the message payload and have the Tuscany runtime sort out
> > transforming it as
> > required by other component types?
> I think we should look at taking Raymond's transformer and making it
> a system service rather than having the core directly have this
> knowledge. This way, it compartmentalizes the complexity and allows
> people to swap it out in favor of a different approach if they
> require it.
>
> > Right now thats not possible and each
> > binding and component must always use the Java types from the
> > logical Java
> > interface representation for the payload.
> >
> > None of these 3 things are possible with either the current code or
> > the
> > sandbox code and extension APIs and AFAICT it would be non-trivial
> > to fix.
> >
> While not trivial, I don't think this would be too drastic of a
> change to the sandbox code. The hardest part I think will be coming
> up with a representation that is usable and not overly complicated
> (like what we had before switching to Method).
>
> > Do we want to support any of these in M2? I'd really like to
> > support at
> > least the middle one.
> Regardless of whether we have an M2 or not n the short-term, I
> definitely think this is something we need to figure out ASAP.
> >
> > ...ant
> >
> > On 6/22/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>
> >> Jean-Sebastien Delfino wrote:
> >> > - The whole interface definition space, like you said we need a
> >> nice way
> >> > to deal with Java and WSDL interfaces, we also need to
> >> understand how
> >> > somebody can extend Tuscany to provide support for additional
> >> interface
> >> > definition languages (e.g. a ruby base class or a ruby module).
> >>
> >> We originally had a logical representation for this and changed
> >> part way
> >> through M1 to using Java interfaces (bytecode generating them from
> >> the
> >> WSDL definition when necessary).
> >>
> >> Do you think we should stick with the pure-Java approach (with
> >> addition
> >> annotations if necessary) or are you thinking of going back to a
> >> logical
> >> representation?
> >>
> >> --
> >> Jeremy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Modeling interface definitions, was: Tuscany SPI interfaces
Posted by Jim Marino <jm...@myromatours.com>.
On Jun 22, 2006, at 2:00 AM, ant elder wrote:
> I've come across difficulties related to this in the work I've done
> with
> extensions:
>
> - I tried adding another interface type a while back in M1 to have an
> interface.smd to support the Dojo Simple Method Description for the
> AJAX
> binding (http://dojo.jot.com/SMD). I couldn't get it to work as the
> current
> code really didn't seem to be designed to support additional interface
> types.
>
> - Another problem already touched on here and earlier in this
> thread by Jim
> is that right now the logical representation is a Java interfaces and
> java.lang.Method is used to represent invocations. Because of this
> I've not
> yet been able to get a component to be able to call a reference using
> non-Java parameters, eg the JavaScript component invoking a
> reference using
> E4X objects. (there's a testcase trying to do this in the rhino
> container in
> my sandbox if you're interested in more details)
>
O.K. I'll take a look but it may take a few days as I'm supposed to
be on vacation but still have a backlog of work to take care of too.
Quick questions:
- You are talking about E4XServiceRefsTestCase?
- HelloWorldProxyImpl flows an invoke to HelloWorldComponent2b which
is another JavaScript component but the intent/point is the target
can be anything?
-An interceptor is interposed in the invocation to handle data
transformation (in this case it could be optimized away since it is a
js-->js invoke)?
- Is SDO needed in the interceptor or is that something you just used
for expediency to do a conversion?
This is going to bring up some interesting questions regarding
policy. I'm wondering if the target invoker should be doing the
transformation as opposed to an interceptor and the target invoker
could just use the data transformation service Raymond was working
on? An interesting issue is if that is the case (or even if we have
an interceptor do the transformation), how do we deal with a policy
interceptor or handler that operates on the body of the messages?
Raymond, would this be a two step process?
Is it possible in Rhino to take an E4X object and pass it by
reference to a JS target? In SCA, we assume pass-by-ref semantics
within a shared memory space and it would be cool if we could
optimize this. Also, it would be interesting if we could do pass-by-
reference from Javascript to Java somehow (e.g. does E4X maintain
some type of backing XML representation that could be passed)?
> - Also related to this is the message format, transformation and
> multiple
> databinding support thats being discussed in other threads and
> JIRAs. Should
> a component or binding be able to put whatever type of object it
> likes into
> the message payload and have the Tuscany runtime sort out
> transforming it as
> required by other component types?
I think we should look at taking Raymond's transformer and making it
a system service rather than having the core directly have this
knowledge. This way, it compartmentalizes the complexity and allows
people to swap it out in favor of a different approach if they
require it.
> Right now thats not possible and each
> binding and component must always use the Java types from the
> logical Java
> interface representation for the payload.
>
> None of these 3 things are possible with either the current code or
> the
> sandbox code and extension APIs and AFAICT it would be non-trivial
> to fix.
>
While not trivial, I don't think this would be too drastic of a
change to the sandbox code. The hardest part I think will be coming
up with a representation that is usable and not overly complicated
(like what we had before switching to Method).
> Do we want to support any of these in M2? I'd really like to
> support at
> least the middle one.
Regardless of whether we have an M2 or not n the short-term, I
definitely think this is something we need to figure out ASAP.
>
> ...ant
>
> On 6/22/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> Jean-Sebastien Delfino wrote:
>> > - The whole interface definition space, like you said we need a
>> nice way
>> > to deal with Java and WSDL interfaces, we also need to
>> understand how
>> > somebody can extend Tuscany to provide support for additional
>> interface
>> > definition languages (e.g. a ruby base class or a ruby module).
>>
>> We originally had a logical representation for this and changed
>> part way
>> through M1 to using Java interfaces (bytecode generating them from
>> the
>> WSDL definition when necessary).
>>
>> Do you think we should stick with the pure-Java approach (with
>> addition
>> annotations if necessary) or are you thinking of going back to a
>> logical
>> representation?
>>
>> --
>> Jeremy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Modeling interface definitions, was: Tuscany SPI interfaces
Posted by ant elder <an...@gmail.com>.
I've come across difficulties related to this in the work I've done with
extensions:
- I tried adding another interface type a while back in M1 to have an
interface.smd to support the Dojo Simple Method Description for the AJAX
binding (http://dojo.jot.com/SMD). I couldn't get it to work as the current
code really didn't seem to be designed to support additional interface
types.
- Another problem already touched on here and earlier in this thread by Jim
is that right now the logical representation is a Java interfaces and
java.lang.Method is used to represent invocations. Because of this I've not
yet been able to get a component to be able to call a reference using
non-Java parameters, eg the JavaScript component invoking a reference using
E4X objects. (there's a testcase trying to do this in the rhino container in
my sandbox if you're interested in more details)
- Also related to this is the message format, transformation and multiple
databinding support thats being discussed in other threads and JIRAs. Should
a component or binding be able to put whatever type of object it likes into
the message payload and have the Tuscany runtime sort out transforming it as
required by other component types? Right now thats not possible and each
binding and component must always use the Java types from the logical Java
interface representation for the payload.
None of these 3 things are possible with either the current code or the
sandbox code and extension APIs and AFAICT it would be non-trivial to fix.
Do we want to support any of these in M2? I'd really like to support at
least the middle one.
...ant
On 6/22/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> Jean-Sebastien Delfino wrote:
> > - The whole interface definition space, like you said we need a nice way
> > to deal with Java and WSDL interfaces, we also need to understand how
> > somebody can extend Tuscany to provide support for additional interface
> > definition languages (e.g. a ruby base class or a ruby module).
>
> We originally had a logical representation for this and changed part way
> through M1 to using Java interfaces (bytecode generating them from the
> WSDL definition when necessary).
>
> Do you think we should stick with the pure-Java approach (with addition
> annotations if necessary) or are you thinking of going back to a logical
> representation?
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Modeling interface definitions, was: Tuscany SPI interfaces
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> Jean-Sebastien Delfino wrote:
>
>> - The whole interface definition space, like you said we need a nice way
>> to deal with Java and WSDL interfaces, we also need to understand how
>> somebody can extend Tuscany to provide support for additional interface
>> definition languages (e.g. a ruby base class or a ruby module).
>>
>
> We originally had a logical representation for this and changed part way
> through M1 to using Java interfaces (bytecode generating them from the
> WSDL definition when necessary).
>
> Do you think we should stick with the pure-Java approach (with addition
> annotations if necessary) or are you thinking of going back to a logical
> representation?
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
What I like about the pure Java approach is that it integrates well with
a Java runtime and is "executable" (you can invoke these methods).
What I don't like about it is that generating the Java interfaces is
complicated (I don't want all the extensions that contribute new
interface types to have to mess around with bytecode generation), and
generating a Java representation of the data flowing through the
interfaces assumes a specific Databinding technology, and may not even
be possible in some cases. Also we'll have to define annotations to
carry any metadata that cannot be represented natively in a Java
interface (namespaces for example).
A logical model representation of interfaces is a simpler solution IMO,
but requires to translate the Java interfaces naturally exposed by Java
components to this logical model. And with this approach we also need to
pick a canonical type representation system to model the data flowing
through the interfaces, so extensions will have to handle that the
conversion of their particular type system to the canonical one.
Right now I'm pretty open to any suggestion... I'm currently
experimenting with the pure-Java interface approach, trying to see if we
can design high level utility APIs to make the generation of the Java
interfaces easier for Tuscany extensions to use.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Modeling interface definitions, was: Tuscany SPI interfaces
Posted by Jeremy Boynes <jb...@apache.org>.
Jean-Sebastien Delfino wrote:
> - The whole interface definition space, like you said we need a nice way
> to deal with Java and WSDL interfaces, we also need to understand how
> somebody can extend Tuscany to provide support for additional interface
> definition languages (e.g. a ruby base class or a ruby module).
We originally had a logical representation for this and changed part way
through M1 to using Java interfaces (bytecode generating them from the
WSDL definition when necessary).
Do you think we should stick with the pure-Java approach (with addition
annotations if necessary) or are you thinking of going back to a logical
representation?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have made some progress here.
1) Started to implement a very simple TCP/IP socket binding
2) Prototyped the databinding framework which can be used to hook with
Tuscany message handler/interceptor. (please see my previous note).
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, June 21, 2006 7:10 PM
Subject: Re: Tuscany SPI interfaces
> [snip]
>
> 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.
>>
> I'm not going to do this in the main head stream since this is prototyping
> and design investigation work. I just created an m2-design directory in my
> sandbox for this. I'll put the ruby component implementation extension
> there as soon as it is in a reasonable enough shape.
>
> There's a lot of interesting design and prototyping work where I think you
> can help:
> - Review the ruby implementation extension that I'm going to put there and
> help understand what aspects are missing, where interfaces can be
> improved, simplified and made more approachable.
> - Implement a simple binding extension (System.out/System.in or just
> TCP/IP sockets for example) to help understand the binding extension
> programming model, and see what's common with implementation extensions.
> - The whole interface definition space, like you said we need a nice way
> to deal with Java and WSDL interfaces, we also need to understand how
> somebody can extend Tuscany to provide support for additional interface
> definition languages (e.g. a ruby base class or a ruby module).
> - The interaction with databindings and how a component implementation
> extension or binding extensions specifies what data representation it can
> work with.
>
> This is just a short list of things that come to mind, but the list will
> grow quickly :)
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
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.
>
I'm not going to do this in the main head stream since this is
prototyping and design investigation work. I just created an m2-design
directory in my sandbox for this. I'll put the ruby component
implementation extension there as soon as it is in a reasonable enough
shape.
There's a lot of interesting design and prototyping work where I think
you can help:
- Review the ruby implementation extension that I'm going to put there
and help understand what aspects are missing, where interfaces can be
improved, simplified and made more approachable.
- Implement a simple binding extension (System.out/System.in or just
TCP/IP sockets for example) to help understand the binding extension
programming model, and see what's common with implementation extensions.
- The whole interface definition space, like you said we need a nice way
to deal with Java and WSDL interfaces, we also need to understand how
somebody can extend Tuscany to provide support for additional interface
definition languages (e.g. a ruby base class or a ruby module).
- The interaction with databindings and how a component implementation
extension or binding extensions specifies what data representation it
can work with.
This is just a short list of things that come to mind, but the list will
grow quickly :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Tuscany SPI interfaces
Posted by ant elder <an...@gmail.com>.
+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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>