|
Hi, I've been trying to get up to speed with the SAF (Service
Availability Framework - HA middleware) implementation OpenSAF
(http://www.opensaf.org/) and I was wondering if there were ways to
integrate Erlang with it? P.S. I've been trying to send this email through another email account and it didn't seem to make it to the list. If it does make it in the end then I'm sorry for the multiple posts... Thanks, Frank
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
|
This post has NOT been accepted by the mailing list yet.
(by absolute chance I ran into your question)
I'm pretty much the Java editor for SAF and have some visibility into alternative language mappings for SAF. Right now, the only official SAF mappings are C and Java (with a higher level Java interface standardized via the JCP). There is some work going on in OpenSAF with a scripting language (Perl? Python?) ('cause it's easy and was sort of a side-effect of test frameworks, as I understand). I don't know if Erlang interfaces exist in certain companies, even as Ericsson is a major participant in SAF and OpenSAF. Maybe someone from Ericsson will speak up? I've been thinking about using Erlang/Mnesia for implementing parts of SAF: the IMM service. Still in the thinking stage. It would also be interesting to consider the correspondence between OTP and the SAF Availability Management Framework. Certainly it is possible to integrate Erlang with SAF .. it's just software ;-) Erlang can certainly handle the "escapes" to native transports. Moreover, SAF is very much built on a location transparent, client/servers w/callbacks model which fits well with Erlang/OTP. For the concrete case of OpenSAF (an open source implementation of the SAF standards), the Java mapping was done with JNI wrappers. Not sure how this approach would play with Erlang. It is seductive to think that API's can wrapped and integrated into a single process while preserving semantics, behavior, and safety. I'd personally opt for a well defined message protocol, but the SAF standardization is based on an API.
|
|
This post has NOT been accepted by the mailing list yet.
...not only it is seductive, but I think it is possible to leverage the Erlang OTP framework, specifically, mnesia, supervision trees and process links to do the core SAF services, then provide C and JAVA mappings on top using C nodes and the JInterface or a .NET mapping for that matter. I am not Sure why SAF opted for an API rather than a message protocol that is language neutral, especially in a era where there is no single language that has claim to fame( well, may be 2 have a tie), although one might argue that both C and JAVA are well rooted in the enterprise.
|
|
In reply to this post by Frank (Usenet)
Note: this is a repost as my original attempt never made it. Sorry for any confusion. -- robert
I'm pretty much the Java editor for SAF and have some visibility into alternative language mappings for SAF. Right now, the only official SAF mappings are C and Java (with a higher level Java interface standardized via the JCP). There is some work going on in OpenSAF with a scripting language (Perl? Python?) ('cause it's easy and was sort of a side-effect of test frameworks, as I understand). I don't know if Erlang interfaces exist in certain companies, even as Ericsson is a major participant in SAF and OpenSAF. Maybe someone from Ericsson will speak up? I've been thinking about using Erlang/Mnesia for implementing parts of SAF: the IMM service. Still in the thinking stage. It would also be interesting to consider the correspondence between OTP and the SAF Availability Management Framework. Certainly it is possible to integrate Erlang with SAF .. it's just software ;-) Erlang can certainly handle the "escapes" to native transports. Moreover, SAF is very much built on a location transparent, client/servers w/callbacks model which fits well with Erlang/OTP. For the concrete case of OpenSAF (an open source implementation of the SAF standards), the Java mapping was done with JNI wrappers. Not sure how this approach would play with Erlang. It is seductive to think that API's can wrapped and integrated into a single process while preserving semantics, behavior, and safety. I'd personally opt for a well defined message protocol, but the SAF standardization is based on an API.
|
| Powered by Nabble | Edit this page |
