minutes from the OGF21 session on the Java language binding
Minutes of the meeting of SAGA-RG held at OGF21, oct 17, 2007, 15:15-16:45 notes: Shantenu Jha, Thilo Kielmann agenda: 1. IPR 2. Agenda bashing 3. Java binding for the CORE spec Thilo Kielmann opens the session, explains the IPR rules and hands out the signup sheet It is agreed to begin the session with a short report-out from the "future of DRMAA" session. Here, Dan Templeton reports about the plans to prepare a next DRMAA version as another SAGA package. Both the SAGA and DRMAA groups want to cooperate on this issue. Java binding: Thilo Kielmann is presenting important aspects of the Java binding, as it is currently being developed by his group. fundamental decisions: - design for Java 1.5 - for application portability across multiple implementations, a mechanism like C++ header files is desirable. for this purpose, the language binding presents all SAGA interfaces and classes as interfaces, accompanied by factory classes. These interfaces and classes will have to be used by all implementations, acting like header files. Flags being used, e.g. for file read/write/create operations. ----- The current soluton is based on enumerations. The participants doubt that this solution is ideal. Use of these enumerations is complex due to the method interface of the object. Also, these enums are converted to integers for the operations (e.g., file read); this violates type safety. The participant discuss alternatives for modeling such flags. They favour two options: a) a pure integer-based solution without type safety, but with an easy to use interface and predefined constants (powers of two) b) a real object that never gets casted to integers Proposals for both versions shall be made and posted to the mailing list for comparison and for adopting one of these two approaches. timeout values: -------------- numeric constants such as "nowait" and "waitforever" shall be used instead of 0 and -1 Buffers: ------- it is suggested to check whether the NIO bytebuffer could be used instead of a from-scratch buffer files: ----- SAGA files are POSIX style the Java binding is using exceptions instead of the POSIX error codes The current file implementation is inspired by random files. inputstream and outputstream shall be layered on top of this. tasks: ----- this interface (group) seemingly needs more attention it is suggested to check whether future objects from the concurrency library could be used. the RVTask looks very much like a future the asymmetry between run() and waittask() should be resolved optional parameters: ------------------- it is suggested to add methods (via overloading) that do not have the last parameter for those methods with optional parameters in the SAGA CORE spec. maybe the varargs mechanism might help (whatever becomes easier to use) implicit sessions: ----------------- in SAGA, the default session is used unless specified differently. this means that the factories need additional methods without session parameters. RPC package: ----------- esp here, the varargs package might be useful CPI, adaptor interface: ---------------------- The audience suggests to add an SPI (service provider interface) as part of the Java language binding (currently called CPI in the JavaGAT) This could allow for a standardized adaptor interface, and thus adaptor reuse. Good examples for such an API/SPI combinations are: JAXP, LDAP, DRMAA multiple implementations: ------------------------ the questions was raised whether it would be / should be possible to use multiple SAGA implementations in the same application. It was decided to not support this as no real need is seen. thread safety: ------------- The audience decided that simply requiring thread safety (and synchronization) of SAGA methods would simplify application development. An expected performance impact is considered of lesser importance, as the service times of remote services dominate invocation times anyway.
Some comments below Quoting [Thilo Kielmann] (Oct 18 2007):
timeout values: -------------- numeric constants such as "nowait" and "waitforever" shall be used instead of 0 and -1
A side comment in the session was that this would be useful for C++ as well - I agree.
tasks: -----
this interface (group) seemingly needs more attention
it is suggested to check whether future objects from the concurrency library could be used. the RVTask looks very much like a future
the asymmetry between run() and waittask() should be resolved
An comment here was, too, that this might not be easy, as wait() is reserved, and runtask() would be unconventional (as run() is usually used in Java for runnables). Another comment from Dan was that method templates/generics should work in Java 5, e.g.: saga::file f = ...; saga::task t = f.get_size <Async> (); ssize_t s = t.get_result <ssize_t> (); okok, that is C++, but the point is that something similar is supposedly working in Java as well.
CPI, adaptor interface: ----------------------
The audience suggests to add an SPI (service provider interface) as part of the Java language binding (currently called CPI in the JavaGAT) This could allow for a standardized adaptor interface, and thus adaptor reuse. Good examples for such an API/SPI combinations are: JAXP, LDAP, DRMAA
To simplify the documents, and to allow for implementations which do not use the SPI, we could split that in two documents? Same holds for C++, where we wee encouraged to formally nail down the CPI, to allow for exchangable adaptors. Cheers, Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
I put together an example of the Generics syntax I mentioned: import java.util.Date; public class Main { public static void main(String[] args) { Date d = new Date(); String s = "test"; // Type is inferred from d2 Date d2 = cast(d); // Because we're chaining, type must be provided explicitly String[] ts = Main.<String>cast(s).split("es"); } // We suppress warnings generated by the unchecked cast @SuppressWarnings("unchecked") public static <T> T cast(Object o) { T t = (T)o; return t; } } Hopefully that's clear enough. Daniel Andre Merzky wrote:
Some comments below
Quoting [Thilo Kielmann] (Oct 18 2007):
timeout values: -------------- numeric constants such as "nowait" and "waitforever" shall be used instead of 0 and -1
A side comment in the session was that this would be useful for C++ as well - I agree.
tasks: -----
this interface (group) seemingly needs more attention
it is suggested to check whether future objects from the concurrency library could be used. the RVTask looks very much like a future
the asymmetry between run() and waittask() should be resolved
An comment here was, too, that this might not be easy, as wait() is reserved, and runtask() would be unconventional (as run() is usually used in Java for runnables).
Another comment from Dan was that method templates/generics should work in Java 5, e.g.:
saga::file f = ...; saga::task t = f.get_size <Async> (); ssize_t s = t.get_result <ssize_t> ();
okok, that is C++, but the point is that something similar is supposedly working in Java as well.
CPI, adaptor interface: ----------------------
The audience suggests to add an SPI (service provider interface) as part of the Java language binding (currently called CPI in the JavaGAT) This could allow for a standardized adaptor interface, and thus adaptor reuse. Good examples for such an API/SPI combinations are: JAXP, LDAP, DRMAA
To simplify the documents, and to allow for implementations which do not use the SPI, we could split that in two documents?
Same holds for C++, where we wee encouraged to formally nail down the CPI, to allow for exchangable adaptors.
Cheers, Andre.
Here are the notes from the second session. Thanks for Thilo for taking notes! Cheers, Andre. Quoting [Thilo Kielmann] (Oct 18 2007):
From: Thilo Kielmann <kielmann@cs.vu.nl> To: saga-rg@ogf.org Subject: [SAGA-RG] minutes from the OGF21 session on the Java language binding
Minutes of the meeting of SAGA-RG held at OGF21, oct 17, 2007, 15:15-16:45
notes: Shantenu Jha, Thilo Kielmann
agenda:
1. IPR 2. Agenda bashing 3. Java binding for the CORE spec
Thilo Kielmann opens the session, explains the IPR rules and hands out the signup sheet
It is agreed to begin the session with a short report-out from the "future of DRMAA" session. Here, Dan Templeton reports about the plans to prepare a next DRMAA version as another SAGA package. Both the SAGA and DRMAA groups want to cooperate on this issue.
Java binding:
Thilo Kielmann is presenting important aspects of the Java binding, as it is currently being developed by his group.
fundamental decisions:
- design for Java 1.5 - for application portability across multiple implementations, a mechanism like C++ header files is desirable. for this purpose, the language binding presents all SAGA interfaces and classes as interfaces, accompanied by factory classes. These interfaces and classes will have to be used by all implementations, acting like header files.
Flags being used, e.g. for file read/write/create operations. ----- The current soluton is based on enumerations. The participants doubt that this solution is ideal. Use of these enumerations is complex due to the method interface of the object. Also, these enums are converted to integers for the operations (e.g., file read); this violates type safety.
The participant discuss alternatives for modeling such flags. They favour two options: a) a pure integer-based solution without type safety, but with an easy to use interface and predefined constants (powers of two) b) a real object that never gets casted to integers
Proposals for both versions shall be made and posted to the mailing list for comparison and for adopting one of these two approaches.
timeout values: -------------- numeric constants such as "nowait" and "waitforever" shall be used instead of 0 and -1
Buffers: -------
it is suggested to check whether the NIO bytebuffer could be used instead of a from-scratch buffer
files: ----- SAGA files are POSIX style the Java binding is using exceptions instead of the POSIX error codes The current file implementation is inspired by random files. inputstream and outputstream shall be layered on top of this.
tasks: -----
this interface (group) seemingly needs more attention
it is suggested to check whether future objects from the concurrency library could be used. the RVTask looks very much like a future
the asymmetry between run() and waittask() should be resolved
optional parameters: -------------------
it is suggested to add methods (via overloading) that do not have the last parameter for those methods with optional parameters in the SAGA CORE spec. maybe the varargs mechanism might help (whatever becomes easier to use)
implicit sessions: ----------------- in SAGA, the default session is used unless specified differently. this means that the factories need additional methods without session parameters.
RPC package: -----------
esp here, the varargs package might be useful
CPI, adaptor interface: ----------------------
The audience suggests to add an SPI (service provider interface) as part of the Java language binding (currently called CPI in the JavaGAT) This could allow for a standardized adaptor interface, and thus adaptor reuse. Good examples for such an API/SPI combinations are: JAXP, LDAP, DRMAA
multiple implementations: ------------------------
the questions was raised whether it would be / should be possible to use multiple SAGA implementations in the same application. It was decided to not support this as no real need is seen.
thread safety: ------------- The audience decided that simply requiring thread safety (and synchronization) of SAGA methods would simplify application development. An expected performance impact is considered of lesser importance, as the service times of remote services dominate invocation times anyway. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Hi all, If any of you are going to SC'07 in Reno next week please note that the DESHL, the SAGA-based tool from the DEISA project, will be presented by Kenton D'Mellow (EPCC/DEISA) at the Booth: NIC - John von Neumann Institute for Computing (Booth #2633). Also at the same booth, the DESHL will be used in the OGF GIN demonstration GINSC2007-010: DEISA and Australian Grid Interop (GO!) - a semonstration of a small job workflow between DEISA and Australian Grid (Monash). See (http://forge.gridforum.org/sf/wiki/do/viewPage/projects.gin/wiki/GINSC200701...) for more information. You can also catch Kenton D'Mellow at the EPCC booth. Is anyone else going and doing similar demonstrations/presentations ? If yes, could you please mail the list so that I can ask Kenton to visit and talk to you. Best regards, Terry
Hi Terry, Thanks for the information. Will be sure to catch up with Kenton. There will also be SAGA demos and talks at the CCT/LSU booth, IBM stand and OMII (UK eScience stand). Ole Weidner from the CCT/LSU (and to a lesser extent myself) will be presenting/demonstrating. Although some slots are fixed, some other slots are still be determined. Details will be posted at http://saga.cct.lsu.edu as they become available. (I've asked that your event also be publicised too). Shantenu
Hi all,
If any of you are going to SC'07 in Reno next week please note that the DESHL, the SAGA-based tool from the DEISA project, will be presented by Kenton D'Mellow (EPCC/DEISA) at the Booth: NIC - John von Neumann Institute for Computing (Booth #2633). Also at the same booth, the DESHL will be used in the OGF GIN demonstration GINSC2007-010: DEISA and Australian Grid Interop (GO!) - a semonstration of a small job workflow between DEISA and Australian Grid (Monash).
See (http://forge.gridforum.org/sf/wiki/do/viewPage/projects.gin/wiki/GINSC200701...) for more information.
You can also catch Kenton D'Mellow at the EPCC booth.
Is anyone else going and doing similar demonstrations/presentations ? If yes, could you please mail the list so that I can ask Kenton to visit and talk to you.
Best regards,
Terry -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
participants (5)
-
Andre Merzky -
Daniel Templeton -
Shantenu Jha -
Terry Sloan -
Thilo Kielmann