[DISCUSS] Enterprise remote service

[DISCUSS] Enterprise remote service

Hi all,

As Aries purpose is to provide an entreprise OSGi application
programming model, I guess it should cover the distributed way of using
services/bundles.

For example, in JEE, we can call EJBs remotely (using the remote
interface) using RMI-IIOP.
If I'm re-read the Aries proposal, I can see:
"...deliver run-time componentry that supports applications, running in
an OSGi framework, exploiting enterprise Java technologies common in web
applications and integration scenarios including web application
bundles, remote services integration and JPA".

Is it plan to do quite the same with OSGi bundles: a bundle can call
another bundle service remotely ? It seems that the "remote services
integration" looks like this, isn't it ?
Have you discuss the underlying protocol to use (RMI, RMI-IIOP, anything
else) ?

Sorry if this topic has already been discussed or if my question is not
applicable or interesting :).

I'm very interesting to contribute on this topic (and others of course :)).
I think that a first implementation using RMI and dynamic proxy can
provide distributed bundles services.

> Hi all,
>
> As Aries purpose is to provide an entreprise OSGi application programming
> model, I guess it should cover the distributed way of using
> services/bundles.
>
> For example, in JEE, we can call EJBs remotely (using the remote interface)
> using RMI-IIOP.
> If I'm re-read the Aries proposal, I can see:
> "...deliver run-time componentry that supports applications, running in an
> OSGi framework, exploiting enterprise Java technologies common in web
> applications and integration scenarios including web application bundles,
> remote services integration and JPA".
>
> Is it plan to do quite the same with OSGi bundles: a bundle can call
> another bundle service remotely ? It seems that the "remote services
> integration" looks like this, isn't it ?
> Have you discuss the underlying protocol to use (RMI, RMI-IIOP, anything
> else) ?
>
> Sorry if this topic has already been discussed or if my question is not
> applicable or interesting :).
>
> I'm very interesting to contribute on this topic (and others of course :)).
> I think that a first implementation using RMI and dynamic proxy can provide
> distributed bundles services.
>
> Could you provide me some feedback ?
>
> Thanks
> Regards
> JB
>

Re: [DISCUSS] Enterprise remote service

Hi Jean-Baptiste,

The incubator proposal [1] states, "It is the expectation that Aries
will therefore not be delivering components such as: ... distribution
provider...". This probably doesn't mean we can't do this, but it's
an indication that it might be best left to other projects that focus
on distribution. The OSGi Remote Service spec took a light touch and
therefore enables many existing distribution technologies to be
integrated in as OSGi Distribution Providers.. I like David's
suggestion of making it really easy to consume those existing projects
that are enabling themselves as OSGi Distribution Providers.

> Hi Jean-Baptiste,
>
> There are already two implementations of the OSGi Remote Services spec
> (chapter 13 in the 4.2 compendium) in Apache.
> They are the CXF-DOSGi subproject:
> http://cxf.apache.org/distributed-osgi.html> and an SCA-based one Tuscany: http://tuscany.apache.org/>
> AFAIK there are no plans to move these to Aries just yet, but it would be
> good if we could make the consumption of these really easy for Aries-based
> applications.
>
> Best regards,
>
> David
>
> 2009/10/23 Jean-Baptiste Onofré <[hidden email]>
>
>> Hi all,
>>
>> As Aries purpose is to provide an entreprise OSGi application programming
>> model, I guess it should cover the distributed way of using
>> services/bundles.
>>
>> For example, in JEE, we can call EJBs remotely (using the remote interface)
>> using RMI-IIOP.
>> If I'm re-read the Aries proposal, I can see:
>> "...deliver run-time componentry that supports applications, running in an
>> OSGi framework, exploiting enterprise Java technologies common in web
>> applications and integration scenarios including web application bundles,
>> remote services integration and JPA".
>>
>> Is it plan to do quite the same with OSGi bundles: a bundle can call
>> another bundle service remotely ? It seems that the "remote services
>> integration" looks like this, isn't it ?
>> Have you discuss the underlying protocol to use (RMI, RMI-IIOP, anything
>> else) ?
>>
>> Sorry if this topic has already been discussed or if my question is not
>> applicable or interesting :).
>>
>> I'm very interesting to contribute on this topic (and others of course :)).
>> I think that a first implementation using RMI and dynamic proxy can provide
>> distributed bundles services.
>>
>> Could you provide me some feedback ?
>>
>> Thanks
>> Regards
>> JB
>>
>

Re: [DISCUSS] Enterprise remote service

I have seen the CXF implementation but, correct me if I'm wrong, but we
can have potential performances issue. As the CXF DSW implementation is
based on WebService/SOAP, there is a need to make data binding. If the
"value" object are big and complex, the JAXB or Aegis data binding can
require resources and computation time.
If we consider Remote Services as Remote Interface/Distributed EJB in
the JEE world, a lot of service calls can happen.

The Tuscany SCA implementation is interesting especially with the
quality of service available. Nevertheless, it requires a dependency to
Tuscany SCA in the client (the java API for example).

What do you think of a "pure" RMI implementation ?

Thanks again,
Regards
JB

David Bosschaert wrote:

> Hi Jean-Baptiste,
>
> There are already two implementations of the OSGi Remote Services spec
> (chapter 13 in the 4.2 compendium) in Apache.
> They are the CXF-DOSGi subproject:
> http://cxf.apache.org/distributed-osgi.html> and an SCA-based one Tuscany: http://tuscany.apache.org/>
> AFAIK there are no plans to move these to Aries just yet, but it would
> be good if we could make the consumption of these really easy for
> Aries-based applications.
>
> Best regards,
>
> David
>
> 2009/10/23 Jean-Baptiste Onofré <[hidden email] <mailto:[hidden email]>>
>
> Hi all,
>
> As Aries purpose is to provide an entreprise OSGi application
> programming model, I guess it should cover the distributed way of
> using services/bundles.
>
> For example, in JEE, we can call EJBs remotely (using the remote
> interface) using RMI-IIOP.
> If I'm re-read the Aries proposal, I can see:
> "...deliver run-time componentry that supports applications, running
> in an OSGi framework, exploiting enterprise Java technologies common
> in web applications and integration scenarios including web
> application bundles, remote services integration and JPA".
>
> Is it plan to do quite the same with OSGi bundles: a bundle can call
> another bundle service remotely ? It seems that the "remote services
> integration" looks like this, isn't it ?
> Have you discuss the underlying protocol to use (RMI, RMI-IIOP,
> anything else) ?
>
> Sorry if this topic has already been discussed or if my question is
> not applicable or interesting :).
>
> I'm very interesting to contribute on this topic (and others of
> course :)).
> I think that a first implementation using RMI and dynamic proxy can
> provide distributed bundles services.
>
> Could you provide me some feedback ?
>
> Thanks
> Regards
> JB
>
>

> The Tuscany SCA implementation is interesting especially with the quality
> of service available. Nevertheless, it requires a dependency to Tuscany
> SCA in the client (the java API for example).

What's your concern of the dependency? From OSGi perspective, there is no
Tuscany SCA API dependency. You just code your OSGi application following
the Remote Services using the standard and SCA related (in the effort of
being standardized) properties. Tuscany SCA is the Remote Service Admin
implementation behind the scene and it is transparently to OSGi users.

In SCA, the protocols (bindings) and QoSs (policies) are declarative. The
Tuscany runtime is highly composable and extensible and you can decide which
bindings/policies should be enabled/included. Tuscany already has a rich set
of bindings, including Web Service, RMI, JSONRPC, JSONP, ATOM, JMS, and EJB.
You can add your own if yours is not there. BTW, Tuscany has a databinding
framework that supports various databindings out of the box, such as JAXB,
SDO, DOM, AXIOM, and JSON. The framework handles data transformations
automatically based on the source/target data types.

>
> What do you think of a "pure" RMI implementation ?

We already have the RMI support. In fact, the samples above use RMI to
connect the calculator and its operations.

> The Tuscany SCA implementation is interesting especially with the quality
> of service available. Nevertheless, it requires a dependency to Tuscany
> SCA in the client (the java API for example).

What's your concern of the dependency? From OSGi perspective, there is no
Tuscany SCA API dependency. You just code your OSGi application following
the Remote Services using the standard and SCA related (in the effort of
being standardized) properties. Tuscany SCA is the Remote Service Admin
implementation behind the scene and it is transparently to OSGi users.

In SCA, the protocols (bindings) and QoSs (policies) are declarative. The
Tuscany runtime is highly composable and extensible and you can decide which
bindings/policies should be enabled/included. Tuscany already has a rich set
of bindings, including Web Service, RMI, JSONRPC, JSONP, ATOM, JMS, and EJB.
You can add your own if yours is not there. BTW, Tuscany has a databinding
framework that supports various databindings out of the box, such as JAXB,
SDO, DOM, AXIOM, and JSON. The framework handles data transformations
automatically based on the source/target data types.

>
> What do you think of a "pure" RMI implementation ?

We already have the RMI support. In fact, the samples above use RMI to
connect the calculator and its operations.

Re: [DISCUSS] Enterprise remote service

Just for completeness. In CXF you can also plug in custom data bindings.
E.g. the CXF-DOSGi project also supports an alternate XML over REST (JAXRS)
databinding. I'm sure other data bindings could be added, if there's
interest in that.