Comments on the Riena Project Goals and Relationship to ECF project

{{#eclipseproject:rt.riena}}

Introduction

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 input to the Riena team prior to it's 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.
• Propose 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 views 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 completely with the goal of having network service discovery be optional for remoting. That is, for example, why ECF has two distinct APIs: discovery and remote services. These two APIs can be used in isolation or together, without dependency on one another.

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

Stateless

As stated here, the Riena team identifies the desire to create stateless services. We do not disagree with this desire, but similar to Transparency and with Connectionless above, we believe that there are likely to be use cases that programmers and users will have for stateful protocols implemented via remote services (just as there are stateful local services). Consider, for example, the need for stateful protocols when it comes to authenticating to an arbitrary remote service and then using that authentication state to determine the appropriateness of subsequent remote calls. The successful authentication itself is, in fact, session state, which must be maintained on the service so that subsequent requests can be refused or allowed based upon whether the user has authenticated.

We don't deny that it is desirable to minimize how stateful a protocol is, but because service creators need stateful protocols for some use cases (e.g. security), it's not appropriate to disallow the creation of stateful services in API/infrastructure intended for a variety of use cases.

Transparent User Context

The work described here is interesting, but it's not complete enough for me to say how it would/does relate to the equinox JAAS work and/or ECF. I believe a description of the wire protocol going on underneath the creation of the sessionid would/is required to have a more complete understanding. Note for reference, however that the ECF interface IConnectContext is intended to contain arbitrary information (defined by provider) for use during connection/authentication with a given target.

Attachments and Monitor Transfers

No comments.

Hessian Protocol

An important point is that we expect the serialization/marshaling to be an area where flexibility/pluggability will be needed, as it's germane to questions of interoperability...that is if object serialization is used for an existing service, then in order to use that service then object serialization will be required.

ECF remote services API does not specify what serialization/marshaling is to be used, and allows providers to decide what serialization/marshaling technology they will support. Some can/will even support multiple (or perhaps pluggable) serialization technologies. This flexibility will be required for some use cases, where interoperability with existing services is required (therefore requiring same wire/transport protocol), or reuse of some existing/familiar technology is required or desired (e.g. use of Hessian serialization, use of java object serialization, etc., etc).

Summary Comments and Recommendation

In summary, we think that

• the goals articulated on the Riena Remote Services are fine for a remote services implementation
• Are not appropriate for some use/design cases (e.g. need for non-transparent remoting, need for asynchronous remote service access, need for connection-oriented remoting, need for other serialization/marshaling technology).
• Fit in quite nicely with the ECF remote services and discovery APIs as we've attempted to create our APIs as completely separate from implementations so as to support as many use cases as possible with multiple implementations (e.g. JMS, XMPP, ECF generic, r-OSGi, etc.).

Recommendations

1. Riena's remoting implementation be used to create an ECF remote services provider to correspond with ECF 3.0/Galileo release. A commitment to doing this in this timeframe be jointly made by both teams.
2. Any desired/needed additions to the ECF remote services API identified by the execution of 1 be added for the ECF 3.0/Galileo release cycle.
3. The Riena integration with JAAS and the protocol used for exchanging authentication credentials and permissions be described in more detail, and opportunities/needs identified for moving up necessary methods to ECF remote services API.
4. ECF and Riena team resources be pooled and we work collaboratively to implement RFC 119 as per this ECF enhancement request. ECF's desire and intention is to implement RFC 119 via the abstract ECF remote services API for ECF 3.0/Galileo, and with a Riena-based ECF remote services provider (1), this would allow both Riena and all other ECF remote services providers to be immediately compliant with RFC 119 without having to re-implement the specification separately for each provider.