Jim Waldo comments on a resurrected Jini and OSGi thing...
In fact, OSGi and Jini are service architectures built for completely different contexts. OSGi is a service architecture for services that are in the same address space. It allows you to build programs out of cooperating services. And for that sort of thing, it is pretty good.Exactly what makes Erlang so nice as a "service-oriented" programming language:
- Invoking services in another process is easy.
- There is no distinction between a service in the same address space and one in another address space.
- There are no guaranteed service behaviors, i.e. Erlang faces head-on the problems inherent in distributed systems.
2 comments:
The OSGi service registry also allows you to call services which can be local or remote. However, the core of the discussion is should a call to a service handle the remoteness, or should it be oblivious of this remoteness. My blog goes indepth into this problem, I think you can make it transparent for the developer because the OSGi services are already dynamic, any errors can be modeled in these dynamics.
How does Erlang handle this problem that remote services can be present and not present?
Kind regards,
Peter Kriens
All interprocess communication in Erlang is an unreliable message send. Erlang supports many thousands of processes within one node, and so many more across nodes.
The syntax is essentially the same whether sending a message to a process here or there. Almost as one would tend to use objects and methods in Java or Smalltalk, one would tend to use asynchronous processes in Erlang.
Since all sends are unreliable, a system built in Erlang has to account for the inherent problems. i.e. reliability can only be made somewhat transparent and sooner or later the system must account for that.
Post a Comment