Configuring DOSGI to use JAX-WS

[Josh Holtzman]

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

[Eoghan Glynn-4]

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
>
>

[Sergey Beryozkin-2]

Hi

One problematic aspect of the Aegis databinding is that hard to write an Aegis-bound code that will interoperate with non-Aegis
consumers or Aegis ones with slightly different understanding of how to interpret a payload. May be enhancing Aegis for it to
produce more predictable descriptions would be one way to preserve the transparency.

 I guess there's a number of reasons why OSGI developers might prefer to do JAXWS & DOSGI. Those (CXF users) who would like to work
in OSGI and use JAXWS without DOSGI would have to
* provide for an explicit jaxws client and or endpoint setup, using either jaxws:endpoint/jaxws:client or doint it programmatically
in a BundleActivator
* These bundles will be more coarse-grained in a sense that an actual JAXWS endpoint implementation may not have an interface or
even if it will, this interface will unlikey to feature in OSGI consoles, that is you won't see with "> services" that a
jaxws:endpoint has been created
* The issue of publication/discovery is open

so if we go to DOSGI & JAXWS now then we have :

* implicit jaxws endpoint / client creation with the help of dosgi properties
* the interfaces are explicitly registered/looked up in BundleActivators which makes them visible from a console
* service publication + discovery is there

I guess the same reasoning could be applied to DOSGI + JAXRS which is something I'm hoping to do...

cheers, Sergey

----- Original Message -----
From: "Eoghan Glynn" <eoglynn@...>
To: <users@...>
Sent: Tuesday, May 12, 2009 10:54 AM
Subject: Re: Configuring DOSGI to use JAX-WS


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]

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

[Eoghan Glynn-4]

Yeah, I see your point about the the Discovery interaction, though I
guess this could be achieved directly from a pure JAX-WS application
by just registering a ServicePublication.

However, just thinking through the Discovery aspect for a moment,
would it be a case of directly exposing the JAX-WS service endpoint
interface as the published service?

In that case, wouldn't the JAX-WS annotation classes have to be pulled
in on the client-side also? I'm thinking here of the case where the
client is a "pure" OSGi client and has no awareness that JAX-WS is
being used on the server-side. Well, I guess these annotation classes
could be bundled up in the "interface bundle" so that they become
available fairly transparently on the client-side.

One other point that occurred to me ... in a pure JAX-WS application,
you're pretty much guaranteed that only full-on remote invocations
will be dispatched to the implementor (modulo the collocated case).
But involving dOSGi would require exposing the SEI as a locally
available POJO-style service via the local OSGi service registry. This
may not be ideal.

Cheers,
Eoghan

2009/5/12 Sergey Beryozkin <sberyozk@...>:

> Hi
>
> One problematic aspect of the Aegis databinding is that hard to write an
> Aegis-bound code that will interoperate with non-Aegis consumers or Aegis
> ones with slightly different understanding of how to interpret a payload.
> May be enhancing Aegis for it to produce more predictable descriptions would
> be one way to preserve the transparency.
>
> I guess there's a number of reasons why OSGI developers might prefer to do
> JAXWS & DOSGI. Those (CXF users) who would like to work in OSGI and use
> JAXWS without DOSGI would have to
> * provide for an explicit jaxws client and or endpoint setup, using either
> jaxws:endpoint/jaxws:client or doint it programmatically in a
> BundleActivator
> * These bundles will be more coarse-grained in a sense that an actual JAXWS
> endpoint implementation may not have an interface or even if it will, this
> interface will unlikey to feature in OSGI consoles, that is you won't see
> with "> services" that a jaxws:endpoint has been created
> * The issue of publication/discovery is open
>
> so if we go to DOSGI & JAXWS now then we have :
>
> * implicit jaxws endpoint / client creation with the help of dosgi
> properties
> * the interfaces are explicitly registered/looked up in BundleActivators
> which makes them visible from a console
> * service publication + discovery is there
>
> I guess the same reasoning could be applied to DOSGI + JAXRS which is
> something I'm hoping to do...
>
> cheers, Sergey
>
> ----- Original Message ----- From: "Eoghan Glynn" <eoglynn@...>
> To: <users@...>
> Sent: Tuesday, May 12, 2009 10:54 AM
> Subject: Re: Configuring DOSGI to use JAX-WS
>
>
> 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
>>
>>
>
>

[Eoghan Glynn-4]

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
>
>

[Josh Holtzman]

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
>>
>>
>>    

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[Josh Holtzman]

I'm finally coming back to looking at this issue.  I've added a Jira and
a patch at https://issues.apache.org/jira/browse/CXF-2252

Let me know if there's anything I can do to clean up the patch.  Since
the current Aegis databinding remains the default, I'm hoping that this
patch can be merged without causing any problems.

Thanks,
Josh

Josh Holtzman wrote:

> 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
>>>
>>>
>>>    
>

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[bimargulies]

I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
JAX-WS. Are you really replacing Simple with JAX-WS, or are you
replacing both?

On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman <jholtzman@...> wrote:

> I'm finally coming back to looking at this issue.  I've added a Jira and a
> patch at https://issues.apache.org/jira/browse/CXF-2252
>
> Let me know if there's anything I can do to clean up the patch.  Since the
> current Aegis databinding remains the default, I'm hoping that this patch
> can be merged without causing any problems.
>
> Thanks,
> Josh
>
> Josh Holtzman wrote:
>>
>> 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
>>>>
>>>>
>>>>
>>
>
> --
> Josh Holtzman
> Educational Technology Services, UC Berkeley
> jholtzman@...
> 510.529.9225
>
>

[Josh Holtzman]

I'm the confused one :)  I was conflating the two.  Daniel Kulp pointed
this out in the Jira ticket, and I've changed the patch so it now
watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and
org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
databinding is used instead of aegis.  If the second property is true,
the jaxws frontend is used rather than the simple frontend.

Josh

Benson Margulies wrote:

> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
> replacing both?
>
> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman <jholtzman@...> wrote:
>  
>> I'm finally coming back to looking at this issue.  I've added a Jira and a
>> patch at https://issues.apache.org/jira/browse/CXF-2252
>>
>> Let me know if there's anything I can do to clean up the patch.  Since the
>> current Aegis databinding remains the default, I'm hoping that this patch
>> can be merged without causing any problems.
>>
>> Thanks,
>> Josh
>>
>> Josh Holtzman wrote:
>>    
>>> 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
>>>>>
>>>>>
>>>>>
>>>>>          
>> --
>> Josh Holtzman
>> Educational Technology Services, UC Berkeley
>> jholtzman@...
>> 510.529.9225
>>
>>
>>    

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[Sergey Beryozkin-2]

Hi,

I'm planning to integrate JAX-RS runtime into a DOSGi as well.

One can consider that

org.apache.cxf.dosgi.frontend.simple

is a default property.

org.apache.cxf.dosgi.frontend.jaxws

would cause a jaxws frontend be used.

Perhaps

org.apache.cxf.dosgi.frontend.jaxrs

can indicate that JAX-RS should be used.

Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
frontend can use JAXB. And all of them can use Aegis

So as far as databinding is concerned, should it be rather    

org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans

org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)

org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis

etc

so that a databinding can be applied selectively, on a per-frontend
basis ?

May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
as a global property which has to apply to all frontends, that is if is
is set then even a simple frontend should use JAXB, but a property like

 
org.apache.cxf.dosgi.frontend.simple.databinding.aegis

can be used to override it

cheers, Sergey


-----Original Message-----
From: Josh Holtzman [mailto:jholtzman@...]
Sent: 05 June 2009 21:30
To: users@...
Subject: Re: Configuring DOSGI to use JAX-WS

I'm the confused one :)  I was conflating the two.  Daniel Kulp pointed
this out in the Jira ticket, and I've changed the patch so it now
watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and
org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
databinding is used instead of aegis.  If the second property is true,
the jaxws frontend is used rather than the simple frontend.

Josh

Benson Margulies wrote:
> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
> replacing both?
>
> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman <jholtzman@...>
wrote:
>  
>> I'm finally coming back to looking at this issue.  I've added a Jira
and a
>> patch at https://issues.apache.org/jira/browse/CXF-2252
>>
>> Let me know if there's anything I can do to clean up the patch.
Since the
>> current Aegis databinding remains the default, I'm hoping that this
patch
>> can be merged without causing any problems.
>>
>> Thanks,
>> Josh
>>
>> Josh Holtzman wrote:
>>    
>>> 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
>>>>>
>>>>>
>>>>>
>>>>>          
>> --
>> Josh Holtzman
>> Educational Technology Services, UC Berkeley
>> jholtzman@...
>> 510.529.9225
>>
>>
>>    

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[dkulp]

Would it make more sense to just have two keys:

org.apache.cxf.dosgi.databinding
org.apache.cxf.dosgi.frontend

that instead of being booleans, would be strings that defined what to use.  
"jaxb"/"aegis" (maybe sdo or xmlbeans in the future?) or
"simple"/"jaxws"/"jaxrs".

Certainly more extensible going forward.

Dan



On Fri June 5 2009 4:46:13 pm Sergey Beryozkin wrote:

> Hi,
>
> I'm planning to integrate JAX-RS runtime into a DOSGi as well.
>
> One can consider that
>
> org.apache.cxf.dosgi.frontend.simple
>
> is a default property.
>
> org.apache.cxf.dosgi.frontend.jaxws
>
> would cause a jaxws frontend be used.
>
> Perhaps
>
> org.apache.cxf.dosgi.frontend.jaxrs
>
> can indicate that JAX-RS should be used.
>
> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
> frontend can use JAXB. And all of them can use Aegis
>
> So as far as databinding is concerned, should it be rather
>
> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans
>
> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)
>
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis
>
> etc
>
> so that a databinding can be applied selectively, on a per-frontend
> basis ?
>
> May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
> as a global property which has to apply to all frontends, that is if is
> is set then even a simple frontend should use JAXB, but a property like
>
>
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis
>
> can be used to override it
>
> cheers, Sergey
>
>
> -----Original Message-----
> From: Josh Holtzman [mailto:jholtzman@...]
> Sent: 05 June 2009 21:30
> To: users@...
> Subject: Re: Configuring DOSGI to use JAX-WS
>
> I'm the confused one :)  I was conflating the two.  Daniel Kulp pointed
> this out in the Jira ticket, and I've changed the patch so it now
> watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and
> org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
> databinding is used instead of aegis.  If the second property is true,
> the jaxws frontend is used rather than the simple frontend.
>
> Josh
>
> Benson Margulies wrote:
> > I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
> > JAX-WS. Are you really replacing Simple with JAX-WS, or are you
> > replacing both?
> >
> > On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman <jholtzman@...>
>
> wrote:
> >> I'm finally coming back to looking at this issue.  I've added a Jira
>
> and a
>
> >> patch at https://issues.apache.org/jira/browse/CXF-2252
> >>
> >> Let me know if there's anything I can do to clean up the patch.
>
> Since the
>
> >> current Aegis databinding remains the default, I'm hoping that this
>
> patch
>
> >> can be merged without causing any problems.
> >>
> >> Thanks,
> >> Josh
> >>
> >> Josh Holtzman wrote:
> >>> 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
> >>
> >> --
> >> Josh Holtzman
> >> Educational Technology Services, UC Berkeley
> >> jholtzman@...
> >> 510.529.9225

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

[Josh Holtzman]

I think this can all be handled with just two properties:

org.apache.cxf.dosgi.databinding=[ jaxb | xmlbeans | aegis (default) ]
org.apache.cxf.dosgi.frontend=[ jaxws | jaxrs | simple (default) ]

This way, you can just mix and match.  Does that meet your needs?

I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in
the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS.  
Is that what you're working on?

Josh

Sergey Beryozkin wrote:

> Hi,
>
> I'm planning to integrate JAX-RS runtime into a DOSGi as well.
>
> One can consider that
>
> org.apache.cxf.dosgi.frontend.simple
>
> is a default property.
>
> org.apache.cxf.dosgi.frontend.jaxws
>
> would cause a jaxws frontend be used.
>
> Perhaps
>
> org.apache.cxf.dosgi.frontend.jaxrs
>
> can indicate that JAX-RS should be used.
>
> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
> frontend can use JAXB. And all of them can use Aegis
>
> So as far as databinding is concerned, should it be rather    
>
> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans
>
> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)
>
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis
>
> etc
>
> so that a databinding can be applied selectively, on a per-frontend
> basis ?
>
> May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
> as a global property which has to apply to all frontends, that is if is
> is set then even a simple frontend should use JAXB, but a property like
>
>  
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis
>
> can be used to override it
>
> cheers, Sergey
>
>
> -----Original Message-----
> From: Josh Holtzman [mailto:jholtzman@...]
> Sent: 05 June 2009 21:30
> To: users@...
> Subject: Re: Configuring DOSGI to use JAX-WS
>
> I'm the confused one :)  I was conflating the two.  Daniel Kulp pointed
> this out in the Jira ticket, and I've changed the patch so it now
> watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and
> org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
> databinding is used instead of aegis.  If the second property is true,
> the jaxws frontend is used rather than the simple frontend.
>
> Josh
>
> Benson Margulies wrote:
>  
>> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
>> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
>> replacing both?
>>
>> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman <jholtzman@...>
>>    
> wrote:
>  
>>  
>>    
>>> I'm finally coming back to looking at this issue.  I've added a Jira
>>>      
> and a
>  
>>> patch at https://issues.apache.org/jira/browse/CXF-2252
>>>
>>> Let me know if there's anything I can do to clean up the patch.
>>>      
> Since the
>  
>>> current Aegis databinding remains the default, I'm hoping that this
>>>      
> patch
>  
>>> can be merged without causing any problems.
>>>
>>> Thanks,
>>> Josh
>>>
>>> Josh Holtzman wrote:
>>>    
>>>      
>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>          
>>>>>>            
>>> --
>>> Josh Holtzman
>>> Educational Technology Services, UC Berkeley
>>> jholtzman@...
>>> 510.529.9225
>>>
>>>
>>>    
>>>      
>
>  

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[Sergey Beryozkin-2]

I agree it makes sense.

I was also thinking about strings, but I was more concerned about the
case when say multiple frontends are used in a given OSGI container
instance, so
Say for a given service Aegis is ok (irrespectively of which frontend is
used) but may be for another service it has to be JAXB (or xmlbeans or
sdo).

So I'm ok with

org.apache.cxf.dosgi.databinding
org.apache.cxf.dosgi.frontend

but just suggesting that an ability to override a databinding on a
per-frontend basis is also taken into account, ex :

org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans

one would use this property only if the global property like

org.apache.cxf.dosgi.databinding.jaxb has to be overridden

may be we can consider adding such a possibility to override once the
real need for it arises...

cheers, Sergey

-----Original Message-----
From: Daniel Kulp [mailto:dkulp@...]
Sent: 05 June 2009 21:58
To: users@...
Cc: Sergey Beryozkin
Subject: Re: Configuring DOSGI to use JAX-WS


Would it make more sense to just have two keys:

org.apache.cxf.dosgi.databinding
org.apache.cxf.dosgi.frontend

that instead of being booleans, would be strings that defined what to
use.  
"jaxb"/"aegis" (maybe sdo or xmlbeans in the future?) or
"simple"/"jaxws"/"jaxrs".

Certainly more extensible going forward.

Dan



On Fri June 5 2009 4:46:13 pm Sergey Beryozkin wrote:

> Hi,
>
> I'm planning to integrate JAX-RS runtime into a DOSGi as well.
>
> One can consider that
>
> org.apache.cxf.dosgi.frontend.simple
>
> is a default property.
>
> org.apache.cxf.dosgi.frontend.jaxws
>
> would cause a jaxws frontend be used.
>
> Perhaps
>
> org.apache.cxf.dosgi.frontend.jaxrs
>
> can indicate that JAX-RS should be used.
>
> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
> frontend can use JAXB. And all of them can use Aegis
>
> So as far as databinding is concerned, should it be rather
>
> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans
>
> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)
>
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis
>
> etc
>
> so that a databinding can be applied selectively, on a per-frontend
> basis ?
>
> May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
> as a global property which has to apply to all frontends, that is if

is
> is set then even a simple frontend should use JAXB, but a property
like

>
>
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis
>
> can be used to override it
>
> cheers, Sergey
>
>
> -----Original Message-----
> From: Josh Holtzman [mailto:jholtzman@...]
> Sent: 05 June 2009 21:30
> To: users@...
> Subject: Re: Configuring DOSGI to use JAX-WS
>
> I'm the confused one :)  I was conflating the two.  Daniel Kulp

pointed

> this out in the Jira ticket, and I've changed the patch so it now
> watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and
> org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
> databinding is used instead of aegis.  If the second property is true,
> the jaxws frontend is used rather than the simple frontend.
>
> Josh
>
> Benson Margulies wrote:
> > I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
> > JAX-WS. Are you really replacing Simple with JAX-WS, or are you
> > replacing both?
> >
> > On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman

<jholtzman@...>
>
> wrote:
> >> I'm finally coming back to looking at this issue.  I've added a
Jira

>
> and a
>
> >> patch at https://issues.apache.org/jira/browse/CXF-2252
> >>
> >> Let me know if there's anything I can do to clean up the patch.
>
> Since the
>
> >> current Aegis databinding remains the default, I'm hoping that this
>
> patch
>
> >> can be merged without causing any problems.
> >>
> >> Thanks,
> >> Josh
> >>
> >> Josh Holtzman wrote:
> >>> 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
> >>
> >> --
> >> Josh Holtzman
> >> Educational Technology Services, UC Berkeley
> >> jholtzman@...
> >> 510.529.9225

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

[Sergey Beryozkin-2]

Hi

Please see my last reply to Dan.

If multiple frontends are involved in a given OSGI container instance
then it might be not possible. As I said, I'm supporting the proposed
two properties but suggesting a possibility for a databinding one be
overridden on a per-frontend basis. That said I'm ok with not
considering this option until it's actually required - I reckon it will
be relatively simple to fix when needed.


Cheers, Sergey

-----Original Message-----
From: Josh Holtzman [mailto:jholtzman@...]
Sent: 05 June 2009 22:04
To: users@...
Subject: Re: Configuring DOSGI to use JAX-WS

I think this can all be handled with just two properties:

org.apache.cxf.dosgi.databinding=[ jaxb | xmlbeans | aegis (default) ]
org.apache.cxf.dosgi.frontend=[ jaxws | jaxrs | simple (default) ]

This way, you can just mix and match.  Does that meet your needs?

I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in
the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS.  
Is that what you're working on?

Josh

Sergey Beryozkin wrote:

> Hi,
>
> I'm planning to integrate JAX-RS runtime into a DOSGi as well.
>
> One can consider that
>
> org.apache.cxf.dosgi.frontend.simple
>
> is a default property.
>
> org.apache.cxf.dosgi.frontend.jaxws
>
> would cause a jaxws frontend be used.
>
> Perhaps
>
> org.apache.cxf.dosgi.frontend.jaxrs
>
> can indicate that JAX-RS should be used.
>
> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
> frontend can use JAXB. And all of them can use Aegis
>
> So as far as databinding is concerned, should it be rather    
>
> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans
>
> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)
>
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis
>
> etc
>
> so that a databinding can be applied selectively, on a per-frontend
> basis ?
>
> May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
> as a global property which has to apply to all frontends, that is if

is
> is set then even a simple frontend should use JAXB, but a property
like

>
>  
> org.apache.cxf.dosgi.frontend.simple.databinding.aegis
>
> can be used to override it
>
> cheers, Sergey
>
>
> -----Original Message-----
> From: Josh Holtzman [mailto:jholtzman@...]
> Sent: 05 June 2009 21:30
> To: users@...
> Subject: Re: Configuring DOSGI to use JAX-WS
>
> I'm the confused one :)  I was conflating the two.  Daniel Kulp

pointed
> this out in the Jira ticket, and I've changed the patch so it now
> watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and
> org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
> databinding is used instead of aegis.  If the second property is true,

> the jaxws frontend is used rather than the simple frontend.
>
> Josh
>
> Benson Margulies wrote:
>  
>> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
>> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
>> replacing both?
>>
>> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman

<jholtzman@...>

>>    
> wrote:
>  
>>  
>>    
>>> I'm finally coming back to looking at this issue.  I've added a Jira
>>>      
> and a
>  
>>> patch at https://issues.apache.org/jira/browse/CXF-2252
>>>
>>> Let me know if there's anything I can do to clean up the patch.
>>>      
> Since the
>  
>>> current Aegis databinding remains the default, I'm hoping that this
>>>      
> patch
>  
>>> can be merged without causing any problems.
>>>
>>> Thanks,
>>> Josh
>>>
>>> Josh Holtzman wrote:
>>>    
>>>      
>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>          
>>>>>>            
>>> --
>>> Josh Holtzman
>>> Educational Technology Services, UC Berkeley
>>> jholtzman@...
>>> 510.529.9225
>>>
>>>
>>>    
>>>      
>
>  

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[Josh Holtzman]

Yes, sorry about that.  I missed Dan's reply as I was typing my own.  
The patch that I'm working on inspects each service reference for these
properties, so each service can choose its own databinding and frontend.

Josh

Sergey Beryozkin wrote:

> Hi
>
> Please see my last reply to Dan.
>
> If multiple frontends are involved in a given OSGI container instance
> then it might be not possible. As I said, I'm supporting the proposed
> two properties but suggesting a possibility for a databinding one be
> overridden on a per-frontend basis. That said I'm ok with not
> considering this option until it's actually required - I reckon it will
> be relatively simple to fix when needed.
>
>
> Cheers, Sergey
>
> -----Original Message-----
> From: Josh Holtzman [mailto:jholtzman@...]
> Sent: 05 June 2009 22:04
> To: users@...
> Subject: Re: Configuring DOSGI to use JAX-WS
>
> I think this can all be handled with just two properties:
>
> org.apache.cxf.dosgi.databinding=[ jaxb | xmlbeans | aegis (default) ]
> org.apache.cxf.dosgi.frontend=[ jaxws | jaxrs | simple (default) ]
>
> This way, you can just mix and match.  Does that meet your needs?
>
> I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in
> the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS.  
> Is that what you're working on?
>
> Josh
>
> Sergey Beryozkin wrote:
>  
>> Hi,
>>
>> I'm planning to integrate JAX-RS runtime into a DOSGi as well.
>>
>> One can consider that
>>
>> org.apache.cxf.dosgi.frontend.simple
>>
>> is a default property.
>>
>> org.apache.cxf.dosgi.frontend.jaxws
>>
>> would cause a jaxws frontend be used.
>>
>> Perhaps
>>
>> org.apache.cxf.dosgi.frontend.jaxrs
>>
>> can indicate that JAX-RS should be used.
>>
>> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
>> frontend can use JAXB. And all of them can use Aegis
>>
>> So as far as databinding is concerned, should it be rather    
>>
>> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans
>>
>> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)
>>
>> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis
>>
>> etc
>>
>> so that a databinding can be applied selectively, on a per-frontend
>> basis ?
>>
>> May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
>> as a global property which has to apply to all frontends, that is if
>>    
> is
>  
>> is set then even a simple frontend should use JAXB, but a property
>>    
> like
>  
>>  
>> org.apache.cxf.dosgi.frontend.simple.databinding.aegis
>>
>> can be used to override it
>>
>> cheers, Sergey
>>
>>
>> -----Original Message-----
>> From: Josh Holtzman [mailto:jholtzman@...]
>> Sent: 05 June 2009 21:30
>> To: users@...
>> Subject: Re: Configuring DOSGI to use JAX-WS
>>
>> I'm the confused one :)  I was conflating the two.  Daniel Kulp
>>    
> pointed
>  
>> this out in the Jira ticket, and I've changed the patch so it now
>> watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and
>> org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
>> databinding is used instead of aegis.  If the second property is true,
>>    
>
>  
>> the jaxws frontend is used rather than the simple frontend.
>>
>> Josh
>>
>> Benson Margulies wrote:
>>  
>>    
>>> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
>>> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
>>> replacing both?
>>>
>>> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman
>>>      
> <jholtzman@...>
>  
>>>    
>>>      
>> wrote:
>>  
>>    
>>>  
>>>    
>>>      
>>>> I'm finally coming back to looking at this issue.  I've added a Jira
>>>>      
>>>>        
>> and a
>>  
>>    
>>>> patch at https://issues.apache.org/jira/browse/CXF-2252
>>>>
>>>> Let me know if there's anything I can do to clean up the patch.
>>>>      
>>>>        
>> Since the
>>  
>>    
>>>> current Aegis databinding remains the default, I'm hoping that this
>>>>      
>>>>        
>> patch
>>  
>>    
>>>> can be merged without causing any problems.
>>>>
>>>> Thanks,
>>>> Josh
>>>>
>>>> Josh Holtzman wrote:
>>>>    
>>>>      
>>>>        
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>          
>>>>>>>            
>>>>>>>              
>>>> --
>>>> Josh Holtzman
>>>> Educational Technology Services, UC Berkeley
>>>> jholtzman@...
>>>> 510.529.9225
>>>>
>>>>
>>>>    
>>>>      
>>>>        
>>  
>>    
>
>  

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[Sergey Beryozkin-2]

Oh I see, so these properties are on per-service basis. Then my proposal
can be ignored.

Thanks, Sergey

> I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in

> the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS.

> Is that what you're working on?

It's all done, as far as proxy generation is concerned, it works pretty
much the same way as with simple frontend/jaxws. Some information is
here :
http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-ClientAPI

I will start a separate thread.

Thanks, Sergey  

 

-----Original Message-----
From: Josh Holtzman [mailto:jholtzman@...]
Sent: 05 June 2009 22:23
To: users@...
Subject: Re: Configuring DOSGI to use JAX-WS

Yes, sorry about that.  I missed Dan's reply as I was typing my own.  
The patch that I'm working on inspects each service reference for these
properties, so each service can choose its own databinding and frontend.

Josh

Sergey Beryozkin wrote:
> Hi
>
> Please see my last reply to Dan.
>
> If multiple frontends are involved in a given OSGI container instance
> then it might be not possible. As I said, I'm supporting the proposed
> two properties but suggesting a possibility for a databinding one be
> overridden on a per-frontend basis. That said I'm ok with not
> considering this option until it's actually required - I reckon it
will

> be relatively simple to fix when needed.
>
>
> Cheers, Sergey
>
> -----Original Message-----
> From: Josh Holtzman [mailto:jholtzman@...]
> Sent: 05 June 2009 22:04
> To: users@...
> Subject: Re: Configuring DOSGI to use JAX-WS
>
> I think this can all be handled with just two properties:
>
> org.apache.cxf.dosgi.databinding=[ jaxb | xmlbeans | aegis (default) ]
> org.apache.cxf.dosgi.frontend=[ jaxws | jaxrs | simple (default) ]
>
> This way, you can just mix and match.  Does that meet your needs?
>
> I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in

> the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS.

> Is that what you're working on?
>
> Josh
>
> Sergey Beryozkin wrote:
>  
>> Hi,
>>
>> I'm planning to integrate JAX-RS runtime into a DOSGi as well.
>>
>> One can consider that
>>
>> org.apache.cxf.dosgi.frontend.simple
>>
>> is a default property.
>>
>> org.apache.cxf.dosgi.frontend.jaxws
>>
>> would cause a jaxws frontend be used.
>>
>> Perhaps
>>
>> org.apache.cxf.dosgi.frontend.jaxrs
>>
>> can indicate that JAX-RS should be used.
>>
>> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
>> frontend can use JAXB. And all of them can use Aegis
>>
>> So as far as databinding is concerned, should it be rather    
>>
>> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans
>>
>> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)
>>
>> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis
>>
>> etc
>>
>> so that a databinding can be applied selectively, on a per-frontend
>> basis ?
>>
>> May be properties like org.apache.cxf.dosgi.databinding.jaxb can

serve

>> as a global property which has to apply to all frontends, that is if
>>    
> is
>  
>> is set then even a simple frontend should use JAXB, but a property
>>    
> like
>  
>>  
>> org.apache.cxf.dosgi.frontend.simple.databinding.aegis
>>
>> can be used to override it
>>
>> cheers, Sergey
>>
>>
>> -----Original Message-----
>> From: Josh Holtzman [mailto:jholtzman@...]
>> Sent: 05 June 2009 21:30
>> To: users@...
>> Subject: Re: Configuring DOSGI to use JAX-WS
>>
>> I'm the confused one :)  I was conflating the two.  Daniel Kulp
>>    
> pointed
>  
>> this out in the Jira ticket, and I've changed the patch so it now
>> watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and

>> org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
>> databinding is used instead of aegis.  If the second property is
true,

>>    
>
>  
>> the jaxws frontend is used rather than the simple frontend.
>>
>> Josh
>>
>> Benson Margulies wrote:
>>  
>>    
>>> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
>>> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
>>> replacing both?
>>>
>>> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman
>>>      
> <jholtzman@...>
>  
>>>    
>>>      
>> wrote:
>>  
>>    
>>>  
>>>    
>>>      
>>>> I'm finally coming back to looking at this issue.  I've added a

Jira

>>>>      
>>>>        
>> and a
>>  
>>    
>>>> patch at https://issues.apache.org/jira/browse/CXF-2252
>>>>
>>>> Let me know if there's anything I can do to clean up the patch.
>>>>      
>>>>        
>> Since the
>>  
>>    
>>>> current Aegis databinding remains the default, I'm hoping that this
>>>>      
>>>>        
>> patch
>>  
>>    
>>>> can be merged without causing any problems.
>>>>
>>>> Thanks,
>>>> Josh
>>>>
>>>> Josh Holtzman wrote:
>>>>    
>>>>      
>>>>        
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>          
>>>>>>>            
>>>>>>>              
>>>> --
>>>> Josh Holtzman
>>>> Educational Technology Services, UC Berkeley
>>>> jholtzman@...
>>>> 510.529.9225
>>>>
>>>>
>>>>    
>>>>      
>>>>        
>>  
>>    
>
>  

--
Josh Holtzman
Educational Technology Services, UC Berkeley
jholtzman@...
510.529.9225

[David Bosschaert]

+1 - This seems to make a lot of sense to me!

Cheers,

David

2009/6/5 Josh Holtzman <jholtzman@...>:

> I think this can all be handled with just two properties:
>
> org.apache.cxf.dosgi.databinding=[ jaxb | xmlbeans | aegis (default) ]
> org.apache.cxf.dosgi.frontend=[ jaxws | jaxrs | simple (default) ]
>
> This way, you can just mix and match.  Does that meet your needs?
>
> I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in the
> way that JaxWsProxyFactoryBean creates client proxies for JAX-WS.  Is that
> what you're working on?
>
> Josh
>
> Sergey Beryozkin wrote:
>>
>> Hi,
>>
>> I'm planning to integrate JAX-RS runtime into a DOSGi as well.
>>
>> One can consider that
>> org.apache.cxf.dosgi.frontend.simple
>>
>> is a default property.
>>
>> org.apache.cxf.dosgi.frontend.jaxws
>>
>> would cause a jaxws frontend be used.
>>
>> Perhaps
>>
>> org.apache.cxf.dosgi.frontend.jaxrs
>>
>> can indicate that JAX-RS should be used.
>>
>> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple
>> frontend can use JAXB. And all of them can use Aegis
>>
>> So as far as databinding is concerned, should it be rather
>> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans
>>
>> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default)
>>
>> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb
>> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis
>>
>> etc
>>
>> so that a databinding can be applied selectively, on a per-frontend
>> basis ?
>>
>> May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve
>> as a global property which has to apply to all frontends, that is if is
>> is set then even a simple frontend should use JAXB, but a property like
>>
>>  org.apache.cxf.dosgi.frontend.simple.databinding.aegis
>>
>> can be used to override it
>>
>> cheers, Sergey
>>
>>
>> -----Original Message-----
>> From: Josh Holtzman [mailto:jholtzman@...] Sent: 05 June 2009
>> 21:30
>> To: users@...
>> Subject: Re: Configuring DOSGI to use JAX-WS
>>
>> I'm the confused one :)  I was conflating the two.  Daniel Kulp pointed
>> this out in the Jira ticket, and I've changed the patch so it now watches
>> for two properties: org.apache.cxf.dosgi.databinding.jaxb and
>> org.apache.cxf.dosgi.frontend.jaxws.  If the first is true, the jaxb
>> databinding is used instead of aegis.  If the second property is true, the
>> jaxws frontend is used rather than the simple frontend.
>>
>> Josh
>>
>> Benson Margulies wrote:
>>
>>>
>>> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus
>>> JAX-WS. Are you really replacing Simple with JAX-WS, or are you
>>> replacing both?
>>>
>>> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman <jholtzman@...>
>>>
>>
>> wrote:
>>
>>>
>>>
>>>>
>>>> I'm finally coming back to looking at this issue.  I've added a Jira
>>>>
>>
>> and a
>>
>>>>
>>>> patch at https://issues.apache.org/jira/browse/CXF-2252
>>>>
>>>> Let me know if there's anything I can do to clean up the patch.
>>>>
>>
>> Since the
>>
>>>>
>>>> current Aegis databinding remains the default, I'm hoping that this
>>>>
>>
>> patch
>>
>>>>
>>>> can be merged without causing any problems.
>>>>
>>>> Thanks,
>>>> Josh
>>>>
>>>> Josh Holtzman wrote:
>>>>
>>>>>
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>> --
>>>> Josh Holtzman
>>>> Educational Technology Services, UC Berkeley
>>>> jholtzman@...
>>>> 510.529.9225
>>>>
>>>>
>>>>
>>
>>
>
> --
> Josh Holtzman
> Educational Technology Services, UC Berkeley
> jholtzman@...
> 510.529.9225
>
>