[SAGA-RG] minutes from the OGF21 session on the Java language binding

[Andre Merzky]

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 at cs.vu.nl>
> To: saga-rg at 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.
-------------- next part --------------
 

OGF21, Seattle
Wednesday, October 17th, 2007
SAGA Session #2 -- Service and Resource Discovery
-------------------------------------------------

Part I: Service Discovery
-------------------------

  - Notetaker: AM

  - SF walks audience through the document proposal.

  - discussion of Glue 1.3 versus Glue 2.0
  - SF: they different, but essential attribs are present.
  - SF: only different is service self reference, we are 
    trying to get that back in.

  - AM: shouldn't there be a proper reference to Glue?
  - SF: yep, probably should, we add that (TODO)

  - AM: is there a way to how to query for default VOs 
        (e.g. take the session contexts' VOs)
  - SF: maybe, we will think of something... (TODO)

  - ??: results for non authorized backends are silently discarded?
  - SF: yes

  - AM: question about value definitions, e.g. for 'type == RB' versus 
       'type = Resource Broker'
  - SF: type values are not defined by GLUE, use '*' to look around 
        what is there.


  - some discussion about the current C++ implementation, adaptor
    selection, and the ability combine results from multiple adaptors
  - AM/SJ will raise that topic with the SAGA C++ developers
    - SF: want to have control over adaptor selection
    - AM: shortcut: exception 'TryAgain' and store results in CPI
          state?

  - summary:
    - Steven to edit according to comments (TODO)
    - after that, submit to editor for public comment (TODO)


Part II: Resource Discovery
---------------------------

  - Notetaker: TK

  - Q: what covers resource discovery in use cases?
  - A: discover compute resources
    
  - Q: use case details? what do people want? through a service?
  - A: basically only finding hostnames at the moment.
    
  - Q: qhat is the information model?
  - Q: what is the query language? sql? xpath?
  - Q: could we use an extension of the advert service interface?
    
  - GL: cog uses condor matchmaking
    
  - ??: wsrf has discovery mechanism built in
    
  - SJ: go back and collect use cases!
    
  - SF: look at the glue use cases! 
    TODO: Steve searches references
    DONE: https://forge.gridforum.org/sf/go/doc14621?nav=1
    
  - GL: gridway must have an api for res. discovery
    TODO: Andre to check
    
  - ??: express the glue schema as classads?
  - ?? just pass strings? would that bind to certain providers 
    (e.g., SQL vs. MDS)?

  - Summary
    no conclusions on open questions, first check out the mentioned
    use cases.


SF: Steve Fisher
AM: Andre Merzky
SJ: Shantenu Jha
TK: Thilo Kielmann
GK: Gregor von Laszewski
??: can't remember who