DOSGi - Dynamic Web Services (no service interface at compile time)

[Bernd Wiswedel-2 <Be...@gmail.com>]

In my RCP I can expose certain functionality as web service. The service
interface (input/ouput parameter) is unfortunately not known at compile time
but instead computed at runtime. I ran across CXF DOSGI, which allows me to
expose predefined java interfaces as web service (nicely demonstrated in the
greeter demo). 

Can I also use that to create dynamic services? I don't want to use the
service with other OSGi containers, only for dynamic clients. 

Thanks.
-- 
View this message in context: http://old.nabble.com/DOSGi---Dynamic-Web-Services-%28no-service-interface-at-compile-time%29-tp26545343p26545343.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: DOSGi - Dynamic Web Services (no service interface at compile time)

[David Bosschaert <da...@gmail.com>]

Hi Bernd,

On your questions:

(a) instead of going the route of generating the java source code and
compiling that (which should work) you could take a look at libraries
like CGLib (http://cglib.sourceforge.net) or ASM
(http://forge.ow2.org/projects/asm) they should allow you to do this
without having to involve javac. Because of licensing issues depending
on javac can be difficult if you need to redistribute your product. I
think using them should work, but I never tried them with CXF-DOSGi.
(b) the asterisk '*' is a special value. It means "all
interfaces/classes passed as the first argument to the
BundleContext.registerService() call". No other wildcards are
currently supported. However you can easily implement your own
wildcard logic and put a collection or array of interface/class names
on the service.exported.interfaces property. (This property is of type
'String+' which is used in OSGi specs to say that the property value
can be of type: String, Collection<String> or String[])

On the question of having influence on the generated WSDL, I'm not too
sure about how to do that from CXF-DOSGi yet, I know that in the Aegis
databinding you can control this somewhat. Maybe Eoghan, Sergey or
Benson know more about how to do that from DOSGi?

Best regards,

David

2009/12/1 Bernd Wiswedel-2 <Be...@gmail.com>:
>
> Hi David,
>
> Option (1) sounds good to me. Two follow-up questions so far:
> (a) I need to create the services at runtime (it's not just that I'm missing
> the dependency on the bundle that defines the interface -- it's really
> created at runtime depending on some protocol that the user defines in the
> GUI of my RCP, which he eventually exposes via a "Publish" button). Do you
> have any tips on how to generate the class file that defines the service? As
> far as I understand I will need to create a temporary java file and
> programmatically write java code and then compile it in the background in
> order to pass the class to the service registry. I'm thinking of a
> counterpart to the DynamicClientFactory which handles all the technical
> parts. Ideally I would have some control on the wsdl generation to make sure
> that the wsdl looks the same for the same protocol, independent of the cxf
> version.
> (b) Does the "service.exported.interfaces=" support wildcards like, e.g.
> "org.foo.MyService*", or is '*' a very special value?
>
> Thanks!
>  Bernd
> --
> View this message in context: http://old.nabble.com/DOSGi---Dynamic-Web-Services-%28no-service-interface-at-compile-time%29-tp26545343p26588092.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>

Re: DOSGi - Dynamic Web Services (no service interface at compile time)

[Bernd Wiswedel-2 <Be...@gmail.com>]

Hi David,

Option (1) sounds good to me. Two follow-up questions so far:
(a) I need to create the services at runtime (it's not just that I'm missing
the dependency on the bundle that defines the interface -- it's really
created at runtime depending on some protocol that the user defines in the
GUI of my RCP, which he eventually exposes via a "Publish" button). Do you
have any tips on how to generate the class file that defines the service? As
far as I understand I will need to create a temporary java file and
programmatically write java code and then compile it in the background in
order to pass the class to the service registry. I'm thinking of a
counterpart to the DynamicClientFactory which handles all the technical
parts. Ideally I would have some control on the wsdl generation to make sure
that the wsdl looks the same for the same protocol, independent of the cxf
version.
(b) Does the "service.exported.interfaces=" support wildcards like, e.g. 
"org.foo.MyService*", or is '*' a very special value?

Thanks!
 Bernd
-- 
View this message in context: http://old.nabble.com/DOSGi---Dynamic-Web-Services-%28no-service-interface-at-compile-time%29-tp26545343p26588092.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: DOSGi - Dynamic Web Services (no service interface at compile time)

[David Bosschaert <da...@gmail.com>]

Hi Bernd,

There are two ways in which you could do this with CXF-DOSGi.

1. With DOSGi you simply register your Java Object as an OSGi Service
with the following Service Registration property:
  service.exported.interfaces=...
As the value you provide the name or names of all the interfaces (or
classes) that you want to expose remotely. Or you can put in '*' which
means all of the interfaces/classes that you pass to
BundleContext.registerService() are exposed.
You don't need to know this value at compile time. You can set it at
runtime. So if you have an object and you want to expose it remotely,
you could in theory put in
service.exported.interfaces=myObject.getClass().getName() or something
like that. As long as the API of the object that you're trying to
remote is suitable for distribution.

2. If you aren't involved in registering the service in the OSGi
Service Registry, you can still expose it remotely. This can be done
by putting a 'service-decorations' file in a bundle which defines
matching rules for any service in the Service Registry and adds extra
properties (like the service.exported.interfaces property) to those
services for how CXF-DOSGi sees them. For more info see at the bottom
of: http://cxf.apache.org/distributed-osgi-reference.html

If you have the choice, I would definitely use option 1, as 2 is a
CXF-DOSGi-specific addition (not part of the OSGi Remote Services)
spec, and option 1 gives you more control.

Again, remember CXF-DOSGi doesn't support all types of Java
interfaces. See the following thread for some information on what is
supported: http://old.nabble.com/Re:-Problem-with-Distributed-OSGi-and-complex-data-types-(AWT)-td26329316.html

Hope this helps,

David

2009/11/27 Bernd Wiswedel-2 <Be...@gmail.com>:
>
>
> In my RCP I can expose certain functionality as web service. The service
> interface (input/ouput parameter) is unfortunately not known at compile time
> but instead computed at runtime. I ran across CXF DOSGI, which allows me to
> expose predefined java interfaces as web service (nicely demonstrated in the
> greeter demo).
>
> Can I also use that to create dynamic services? I don't want to use the
> service with other OSGi containers, only for dynamic clients.
>
> Thanks.
> --
> View this message in context: http://old.nabble.com/DOSGi---Dynamic-Web-Services-%28no-service-interface-at-compile-time%29-tp26545343p26545343.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>