Difference between revisions of "Comments on the Riena Project Goals and Relationship to ECF project"

Revision as of 19:56, 12 January 2009

On the Riena RemoteServices wiki page, the Riena team lists some of the goals associated with the remote services part of Riena.

This document is a commentary on some of those goals. The commentary is meant to

• Clarify some technical points around the goals as stated in the Riena RemoteServices wiki page.
• Provide some (hopefully helpful) input to the Riena team prior tom the Riena project 1.0 release review.
• Describe the relationship between these goals and the goals of the ECF project's work on remote services and discovery.
• Describe and propose joint future work between the Riena team post 1.0, and the ongoing ECF 3.0 work.

Comments on Riena Goals

Transparency

Network transparency in distributed applications is a very controversial subject. Some believe that remote services (as distinct from within-process or local OSGi services) differ so fundamentally from local services...in terms of performance partial failure and other network characteristics...that providing transparency in remote access to services (essentially java objects) is doomed to eventual failure. For example, consider the view expressed in this article and subsequent comments: Distributed OSGi - Tilting at Windmills.

Others believe that network transparency in distributed applications is the only way to go in order to get adoption/usage by many programmers...primarily based upon the very reasonable assumption that it's simpler for the programmer to not have to deal with service access in two different ways (i.e. local services and remote services) at the middleware and/or higher levels and that simpler, more consistent APIs across local and remote services will translate into greater usage, adoption, and more applications that effectively use distributed services.

As articulated here, the Riena team seems to be taking the latter approach to transparency.

As an alternative to the extremes articulated above, ECF's remote services work takes an agnostic approach to this general design question...with the expectation that application-level requirements for performance, reliability, security, etc will determine whether/how much transparency is appropriate at the service interface level. That is, our expectation is that some application-level use of services will operate just fine in with a completely transparent approach (i.e. no difference between a local and remote service in terms of the API), while others will require more explicit handling of (e.g.) network failure, network performance issues, asynchronous vs. synchronous remote method invocation, etc).

To support a wide range of applications, the ECF remote services APIs have been constructed to support both transparent access to remote services and more explicit access. So, for example, if a service publisher wishes to expose a service transparently to some set of others, then she may do so without having to do anything different than a normal local service registration. If, OTOH, it is desired to expose a service explicitly to a given set of clients, or to allow those clients to more easily detect failure conditions, or invoke the remote service asynchronously, or impose runtime constraints upon timeout conditions, etc. then those that desire or require these things can get at them via a familiar and consistent runtime API.

It's my view that at the API level that it's necessary to support a variety of use cases, and so the ECF remote services API supports both transparent and non-transparent service remoting. As discussed with members of the Riena team previously, we believe that it would best serve the Eclipse community to use Riena 1.0 to implement an ECF remote services provider, so that multiple implementations of a single API, which supports both transparent and non-transparent remoting can be used within Eclipse. This has already been done with r-OSGi and although a small technical effort, makes it easy for consumers to get transparent or non-transparent remote access to their remote services.

Discovery Optional

We agree with the goal of having network service discovery be optional. That is why ECF has two distinct APIs: discovery and remote services as presented here].

Connectionless

As stated here the Riena team identifies their approach as connectionless, because it uses http request-response as the transport protocol. Although there is nothing inherently wrong with connectionless implementations, there are some very established and useful connection-oriented protocols (e.g. all flavors of JMS, XMPP, others) that consumers would like to use as transports for remoting. Also, like transparency, sometimes application-level needs dictate the use of connection-oriented protocols rather than connectionless protocols...e.g. for performance needs, or reliability, or interoperability. ECF's remote services API can/has been implemented via both both connection-oriented and connectionless protocols in order to meet as many use cases as possible. It is up to the provider (and not specified in the API) to determine whether they are connectionless or connection-oriented, and the API can accomodate both (e.g. JMS, XMPP both are used as connection-oriented providers of the remote services API, while r-OSGi, like Riena is a connectionless provider).