tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Should host-embedded depend on the WSDL and Java interface support? was: svn commit: r527581
Date Sun, 15 Apr 2007 16:00:59 GMT
Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> On 4/11/07, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>>>
>>> Raymond Feng wrote:
>>> > Hi,
>>> >
>>> > I think we should start to leverage the extensibility story (see the
>>> > thread titled "The pluggability for Tuscany runtime extensions")
>>> > instead of hard-coding all the processors into the SimpleRuntimeImpl.
>>> >
>>> > Thanks,
>>> > Raymond
>>> >
>>> > ----- Original Message ----- From: <jsdelfino@apache.org>
>>> > To: <tuscany-commits@ws.apache.org>
>>> > Sent: Wednesday, April 11, 2007 10:14 AM
>>> > Subject: svn commit: r527581 - in
>>> > /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
>>> > src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>>> >
>>> >
>>>
>>> Raymond,
>>>
>>> I agree that we need to leverage the runtime extensibility story, for
>>> runtime extensions :)
>>>
>>> But are the WSDL and Java interface support really extensions or 
>>> part of
>>> the base SCA assembly support?
>>>
>>> On one hand, no, they are not real extensions as they are part of the
>>> base SCA assembly spec. So we don't need to handle them as extensions,
>>> SimpleRuntimeImpl can depend on them the same way as it depends on the
>>> assembly-xml module.
>>>
>>> On the other hand, we could consider them as extensions, as Java and
>>> WSDL are just two of many programming languages that can be used to
>>> define service interfaces. To do this we just need two new Maven 
>>> modules
>>> hosting their ModuleActivators. Going further, we could even consider
>>> assembly-xml as an extension, and have a ModuleActivator for it as 
>>> well.
>>>
>>> So, our new modularized kernel structure allows for both approaches.
>>> It's a matter of where we want to draw the line between core SCA and
>>> extensions. At the moment, I'm tempted to follow the structure of the
>>> SCA specifications to draw these lines. What's in the SCA assembly spec
>>> is part of the base, what's not in the SCA assembly spec is extensions.
>>> But I could be convinced otherwise...
>>>
>>> Thoughts?
>>
>>
>> I'd be leaning to making them proper extensions unless it makes the code
>> significantly more complicated.
>>
>> One of the problems we've had in the past is that by not making 
>> things like
>> Java 1st class extensions then when it comes to adding something else 
>> as a
>> real extension various issues get exposed. Another thing is that the SCA
>> assembly spec also says that the WS binding MUST be supported by an SCA
>> runtime so following the argument above our Axis2 binding could be 
>> hardcoded
>> into the runtime which doesn't seem right.
>>
>>   ...ant
>>
>
> Ok, good points. Like I said above I could be convinced... both 
> Raymond and you seem to favor that direction so, if anybody has time 
> to create the two new Maven modules (interface-java-runtime and 
> interface-wsdl-runtime) contributing the corresponding 
> ModuleActivators then let's just do that as it's cleaner. If nobody 
> else gets to it before tomorrow then I'll try to do it tomorrow.
>

I have created the two Maven modules contributing the ModuleActivators 
for interface-java and interface-wsdl:
- modules/interface-java-runtime, registers the StAX artifact processor 
for <interface.java>
- modules/interface-wsdl-runtime, registers the StAX artifact processor 
for <interface.wsdl> and the URL artifact processor for WSDL documents

For now I have kept a dependency on these two modules in host-embedded 
(with <scope>runtime</scope>) to avoid having to touch all the samples 
and integration tests that use Java and WSDL interfaces and have to add 
these 2 modules to them individually. Once they all have the correct 
dependencies we can remove the dependency in host-embedded.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message