Re: Configuring DOSGI to use JAX-WS

> Right.  In the SOA world, the WSDL is the service contract.  In the
> Java world, the interface is the service contract.  I therefore see no
> problem using JAX-WS annotations on the Java interfaces, since they
> describe how to translate between Java and WSDL.
>
> Thanks,
> Josh
>
> Eoghan Glynn wrote:
>> Sorry Josh, I didn't notice your response before replying to Sergey.
>>
>> So in your case, it wouldn't actually be an issue that the JAX-WS
>> annotations were present on the OSGi service class?
>>
>> Cheers,
>> Eoghan
>>
>> 2009/5/12 Josh Holtzman <jholtzman@...>:
>>  
>>> Hi Eoghan,
>>> Yes, it would most likely require JAX-WS annotations on the service
>>> interfaces rather than the impl classes, but IMHO it doesn't break
>>> the OSGI
>>> service model.  Perhaps I should explain my use case.
>>>
>>> We are building an open source system that must be able to operate
>>> in both a
>>> co-located (one JVM) and distributed topology.  For the co-located
>>> flavor,
>>> we don't want to incur the overhead of web service serialization...
>>> we want
>>> direct access to the java services as they were published to the OSGI
>>> service registry.  For the distributed topology, we want to allow
>>> adopting
>>> institutions to swap out individual services for their own
>>> implementations
>>> in other languages.  And finally, we want our service clients to be
>>> ignorant
>>> of the current topology.  Service developers should enable their
>>> services to
>>> be available remotely (by publishing with the osgi.remote property
>>> and using
>>> JAX-WS annotations), but should not necessarily expect the services
>>> to be
>>> remote.
>>>
>>> Providing a JAX-WS configuration option shouldn't impact folks
>>> wanting to
>>> stick with aegis/simple.  But it does allow projects that want all
>>> of the
>>> benefits of DOSGI to make their web service contracts usable outside
>>> of the
>>> CXF world.
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>> Eoghan Glynn wrote:
>>>    
>>>> Hi Josh,
>>>>
>>>> I'm not entirely sold on the desirability of using JAX-WS with dOSGi.
>>>>
>>>> Wouldn't this require that the original OSGi service class was
>>>> annotated with @WebService, @WebMethod etc?
>>>>
>>>> And wouldn't this defeat the whole purpose of dOSGi in a sense? i.e.
>>>> if the remotability isn't enabled transparently on a largely unchanged
>>>> OSGi application, why not just write a straight JAX-WS server-side
>>>> application from the get-go?
>>>>
>>>> Sorry if I'm slightly missing the point here. I just wanted to think
>>>> through the implications of using a databinding/frontend that's more
>>>> intrusive than Aegis/simple.
>>>>
>>>> Cheers,
>>>> Eoghan
>>>>
>>>> 2009/5/11 Josh Holtzman <jholtzman@...>:
>>>>
>>>>      
>>>>> I just read David Bosschaert's blog entry [1] addressing questions
>>>>> about
>>>>> his
>>>>> RFC 119 webinar.  One of his answers sparked another question, and
>>>>> rather
>>>>> than contact him directly, I decided to give the wider CXF
>>>>> community a
>>>>> crack
>>>>> at it.
>>>>>
>>>>> I'd like to have the option to specify which databinding strategy
>>>>> to use
>>>>> with DOSGI.  Currently, the Aegis databinding is "hard wired".  I
>>>>> recognize
>>>>> that this makes sense for most use cases, since it relieves the
>>>>> developer
>>>>> from any wsdl or xsd responsibilities.  But it doesn't make sense for
>>>>> cross-platform use cases (which, interestingly, David mentions right
>>>>> after
>>>>> the question "Why don't you use JaxWS?").
>>>>>
>>>>> The default wsdls produced by the Aegis databinding are not easily
>>>>> usable
>>>>> cross-platform.  I wouldn't want to provide a developer with a
>>>>> wsdl that
>>>>> specifies arg0, arg1, and arg2 as argument names, for example.
>>>>>
>>>>> Is there interest in allowing the databinding strategy to be
>>>>> configurable
>>>>> in
>>>>> the DOSGI reference implementation?  If so, I'd be happy to work on a
>>>>> patch.
>>>>>
>>>>> [1]
>>>>>
>>>>> http://coderthoughts.blogspot.com/2009/05/questions-from-rfc-119-webinar.html 
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Josh
>>>>>
>>>>> --
>>>>> Josh Holtzman
>>>>> Educational Technology Services, UC Berkeley
>>>>> jholtzman@...
>>>>> 510.529.9225
>>>>>
>>>>>
>>>>>
>>>>>        
>>> --
>>> Josh Holtzman
>>> Educational Technology Services, UC Berkeley
>>> jholtzman@...
>>> 510.529.9225
>>>
>>>
>>>    
>