October 2007 - saga-rg - lists.ogf.org

NSEntry constructor
by Roelof Kemp 09 Nov '07

09 Nov '07

Hi Andre, I have a few comments about the NSEntry. The notes of the constructor state that all notes from the open call (on ns_directory) apply. * The notes of the open call specify an AlreadyExists exception which is not in the Throws list of the NSEntry constructor. * It is not clear from the description of the ns_directory open call if it should create a new file if: 1. The file does not exists 2. The CREATE flag is set I think it should, is that true? If so, maybe you can add it to the postconditions. Roelof

2 1

minutes from the OGF21 session on the Java language binding
by Thilo Kielmann 09 Nov '07

09 Nov '07

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.

5 5

Some more questions
by Ceriel Jacobs 31 Oct '07

31 Oct '07

Hi Andre, Roelof Kemp came up with some questions/remarks on the ns_entry copy method: 1. The specs mention that a DoesNotExist exception is thrown when the target lies in a non-existing part of the name space. However, DoesNotExist is not listed in the "Throws" list. 2. What is supposed to happen when the source is a directory, the recursive flag is set, and the target is a file? I assume remove target, create target dir, and copy? And if overwrite flag is not set, throw AlreadyExists? 3. What is supposed to happen with a recursive copy where the overwrite flag is NOT set, and some of the destinations already exist? Copy to the non-existing destinations and throw AlreadyExists? Also, could you give Roelof access to the SAGA CVS? Cheers, Ceriel

4 7

Re: [SAGA-RG] small issue in SAGA specs
by Andre Merzky 30 Oct '07

30 Oct '07

Hi Ceriel, Quoting [Ceriel Jacobs] (Oct 30 2007): > > Andre Merzky wrote: > >Thanks, that is a good catch - I fixed that in CVS. > > > >It think, however, that the issue on remove_metric is > >reversed: IncorrectState does not make sense on the > >metric.remove_callback(), as that should be possible on a > >final metric. > > > >So I removed added IncorrectState to > >monitorable.add_callbacj, and removed it from > >metric.remove_callback. Does that make sense for you? > > So metric.remove_callback on a final metric always gives > DoesNotExist? (You cannot add callbacks to a final metric, > so the metric cannot have callbacks). A metric can become final during their lifetime, so a callback may have been added earlier. For example, the job.state metric will get final when the job enters a final state. So, if you have the following: saga::job j = js.create_job (jd); saga::metric m = job.get_metric ("job.state"); int cookie = m.add_callback (my_cb); // cb prints "New" j.run (); // cb prints "Running" j.wait (); // cb prints "Done" // metric is final now, so the cb will never be invoked // again - but the cb should still be removable, i.e. in // order to release shared resources hold by the cb. m.remove_callback (cookie); In this case, no exception is thrown. Yes, a DoesNotExist exception would be thrown if, for example, the cookie is used twice for removal - but a IncorrectState exception would make no sense, IMHO. Cheers, Andre. > Ceriel > -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

1 0

Re: [SAGA-RG] minutes from the OGF21 session on the Java language binding
by Andre Merzky 19 Oct '07

19 Oct '07

Hi Dan, cold you please clarify, or send us a pointer, on what you meant in the session? I may have misunderstood your comment... Thanks, Andre. Quoting [Ceriel Jacobs] (Oct 19 2007): > > Andre Merzky wrote: > > Some comments below > > > > > 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. > > Not true. There are no method templates in Java. > > Ceriel -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

2 3

Re: [SAGA-RG] SAGA questions ...
by Andre Merzky 19 Oct '07

19 Oct '07

Hi Ceriel, I Cc the mailing list as it would be good to include others in the language binding discussion... Quoting [Ceriel Jacobs] (Oct 18 2007): > > Hi Andre, > > I am now starting to implement some of the SAGA stuff on top of javaGAT, > and have a couple of new questions, but am also leaving on holiday for > a week (until Oct 29), so I don't need an immediate answer. I will be > in a hurry when I get back, though ;-) > Anyway, here are the questions: > > 1. monitoring/metrics: > The metrics are supposed to do callbacks. These callbacks take > a.o. a Monitorable and a Context. I haven't got a clue where to > get them from. I would expect them to live in the metric, > but they don't. At least, they are not provided in the constructor > of the metric (see the SAGA specs, page 123 in my version).They are > also not provided in the fire() method. So, where to get them from? The use case is as follows: ------------------------------------------------------------------ A) saga::job j = js.run_job (...); j.add_callback ("state", my_cb); j.wait (); ------------------------------------------------------------------ B) saga::job j = js.run_job (...); saga::metric m = j.get_metric ("state"); m.add_callback (my_cb); j.wait (); ------------------------------------------------------------------ In both cases, the metric 'knows' from what monitorable it comes from. The metric should store that internally, and give it to the cb on invocation. The direct constructor for the metric is actually rarely needed - the only use case for that is, at the moment, if an application registers an own metric: ------------------------------------------------------------------ saga::job_self self = js.get_self (); saga::metric m ("test_metric", ...); self.add_metric (m); ------------------------------------------------------------------ In this case, the metric knows the monitorable as well: its self. If a metric is just created, and never attached to a monitorable, it can never change, so the callback cannot be called, so you don't need the monitorable ;-) About the context: that context is supposed to represent the _remote_ entity, the one who caused the metric to change. For example, if a job state changes to failed, the context should be the one representing the credential of the job service who is reporting that state change. That context will often not be available - in that case, an 'Unknown' context is returned. The main use case is actually for streams, where the remote party can be authenticated/authorized to create a connection. > 2. attributes: > What exactly does "removable" mean? A complete removal of the > attribute, so that you cannot specify a new value for it later on, > or just removal of any assigned value? The first one: it can be removed. An example is an attribute on logical files: those are all removable (logical_files have no default attributes). > 3. attributes: > What exactly should listAttributes list? All attributes that > have a value? Or just all supported attributes? Or all > implemented attributes? All attributes that are available, i.e. where I can call get_attribute() upon. An empty value can be valid, so empty attributes should also be listed. All attributes which are listed as non-optional in the spec, and are non-removeable (none of the listed one is removable at the moment) must be listed, potentially with their default values. Optional attribs which are not supported by that implementation should not be listed. Does that make sense? Cheers, Andre. > Cheers, Ceriel. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

1 0

GLUE Use Cases
by Fisher, SM (Steve) 18 Oct '07

18 Oct '07

https://forge.gridforum.org/sf/go/doc14621?nav=1 Steve

1 0

Re: [SAGA-RG] [saga-cvs] "SAGA-RG/Strawman saga_core_design.tex"
by Andre Merzky 16 Oct '07

16 Oct '07

Hmm, why do you think that example is bad? Andre. Quoting [Thilo Kielmann] (Oct 16 2007): > To: saga-cvs(a)cct.lsu.edu > From: Thilo Kielmann <kielmann(a)cs.vu.nl> > Subject: [saga-cvs] "SAGA-RG/Strawman saga_core_design.tex" > > Update of /projects/SAGA-RG/Strawman > In directory asylum.cct.lsu.edu:/tmp/cvs-serv32382 > > Modified Files: > saga_core_design.tex > Log Message: > typo and grammar fixes in section 2 upto and including 2.4 > > added 2 missing look&feel names for "must implement" in 2.4 > > first paragraph of 2.4.1 (early binding): > This is a silly example; can we think of any better?? > > > _______________________________________________ > saga-cvs mailing list > saga-cvs(a)cct.lsu.edu > https://mail.cct.lsu.edu/mailman/listinfo/saga-cvs -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

2 2

Emailing: saga_sd.dvi
by Fisher, SM (Steve) 15 Oct '07

15 Oct '07

<<saga_sd.dvi>> Hi, I attach an update of the proposed SAGA Service Discovery spec. It is now a little simpler with the change to the core API that no longer insists upon default values for attributes. I have also identified the version of the GLUE spec upon which it is based. We have an implementation but we do have some concern with the design of the C++ adapters that we will discuss this week. Steve

2 1

Re: [SAGA-RG] [global-custreqs] Groups - OASIS: 6 New Committees Standardizing SCA for SOA (SCA OASIS - 6 SOA TCs .pdf) uploaded
by Andre Merzky 11 Oct '07

11 Oct '07

Hi Craig, thanks for the deep links! The SCA-C-C++ does indeed sound intriguing! At the moment my guess is that it would provide a generic way to create C/C++ accessors (stubs) for the OASIS middleware standards stack. So, in some sense its like a generic SAGA for OASIS. Interesting for us is that SAGA does, at the moment, has _no_ generic elements - we prescribe all semantic parts of the API as well. At some point we will need a generic part, and should look at the outcome of the SCA-C-C++ effort. IIUC, it requires at least a yearly $300 fee to actively participate in the group (as individual member). Is anybody on this list already OASIS member, or affiliated with an OASIS member organization/company? Swift: at a first glance, it looks not that different from other grid enabled workflow environments, although targeting on more scalable problems. I'm not sure if I missed their point though, will have to dig through their docs more thoroughly :-) SAGA / JSR: Gregor was the one proposing and driving that project, and I assume he still has interest in that. But, AFAIK, he has very tough time constraints :-( So I assume that is on hold until someone else who is comfortable with Java and the JSR process steps up to support that effort. Cheers, Andre. Quoting [Craig Lee] (Sep 12 2007): > To: Andre Merzky <andre(a)merzky.net> > From: Craig Lee <craig(a)rush.aero.org> > Subject: Re: [global-custreqs] Groups - OASIS: 6 New Committees > Standardizing SCA for SOA (SCA OASIS - 6 SOA TCs .pdf) uploaded > Cc: msc(a)ogf.org, saga-rg(a)ogf.org > > > Andre, > > That document is actually just the OASIS press release which > is also available at: > > http://www.oasis-open.org/news/oasis-news-2007-08-09.php > > There's a little bit more info at: > > http://xml.coverpages.org/ni2007-07-06-a.html#SCA-C > > But if you drill down to: > > http://www.oasis-open.org/committees/documents.php?wg_abbrev=sca-c-cpp > > there are still no documents -- perhaps not yet. The charter for > the C-C++ group has some more info: > > http://www.oasis-open.org/committees/sca-c-cpp/charter.php > > but still not specific information. > > > On another topic, what do you SAGA-noids think about Swift? > http://www.ci.uchicago.edu/swift > > On a third topic, is the SAGA group still thinking about sending the Java > binding > through the JSR process? > > --Craig > > > At 06:26 PM 9/10/2007, Andre Merzky wrote: > >The document area seems to be passwd protected - do you know > >if the document publicly is available somewhere? I have to > >admint that I would need to read into it to understand what > >that agglomeration of acronyms really implies :-) > > > >Thanks, Andre. > > > > > >Quoting [Craig Lee] (Sep 10 2007): > >> To: msc(a)ogf.org, saga-rg(a)ogf.org > >> From: Craig Lee <craig(a)rush.aero.org> > >> Subject: [SAGA-RG] Fwd: [global-custreqs] Groups - OASIS: 6 New > >Committees > >> Standardizing SCA for SOA (SCA OASIS - 6 SOA TCs .pdf) uploaded > >> > >> > >> All, > >> > >> The OSOA work (www.osoa.org) is now being sent through the OASIS > >> standardization process. > >> The OSOA approach is SCA (Service Component Architecture) and SDO > >(Service > >> Data Objects) > >> which seems to me like it makes services and data independently > >manageable, > >> a la WSRF. > >> WRT framework, policy, bindings, I wonder how much they are reinventing? > >> WRT the C/C++/Java use in SCA domains, I wonder how much SAGA could do > >this > >> right now? > >> > >> --Craig > >> > >> > >> >Delivered-To: lee(a)aero.org > >> >Mailing-List: contact global-custreqs-help(a)lists.ncoic.org; run by ezmlm > >> >X-No-Archive: yes > >> >List-Post: <mailto:global-custreqs@lists.ncoic.org> > >> >List-Help: <mailto:global-custreqs-help@lists.ncoic.org> > >> >List-Unsubscribe: <mailto:global-custreqs-unsubscribe@lists.ncoic.org> > >> >List-Subscribe: <mailto:global-custreqs-subscribe@lists.ncoic.org> > >> >Delivered-To: mailing list global-custreqs(a)lists.ncoic.org > >> >Date: 10 Sep 2007 12:46:45 -0700 > >> >To: global-custreqs(a)lists.ncoic.org > >> >From: "Steve Russell" <Steve.Russell(a)l-3com.com> > >> >Subject: [global-custreqs] Groups - OASIS: 6 New Committees > >Standardizing > >> >SCA for SOA (SCA OASIS - 6 SOA TCs .pdf) uploaded > >> >Sender: global-custreqs-return-782-lee=aero.org(a)lists.ncoic.org > >> >X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on > >> > rushe.aero.org > >> >X-Spam-Level: > >> >X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 > >autolearn=ham > >> > version=2.60 > >> > > >> >Six OASIS Technical Committees formed for developing NIF-like Service > >> >components, specifications, and developer guidance. > >> > > >> > -- Steve Russell > >> > > >> >The document named OASIS: 6 New Committees Standardizing SCA for > >SOA (SCA > >> >OASIS - 6 SOA TCs .pdf) has been submitted by Steve Russell to the > >> >Requirements Validation FT document repository. > >> > > >> >Document Description: > >> >OASIS, the international open standards consortium, has formed 6 new > >> >technical committees to simplify SOA application development by > >advancing > >> >the Service Component Architecture (SCA) family of specifications. The > >> >work will be organized within the OASIS Open Composite Services > >> >Architecture (Open CSA) Member Section, and the resulting specifications > >> >will be offered for implementation on a royalty-free basis. The six new > >> >Technical Committees (TCs) and their roles are: > >> > > >> >1. SCA-Assembly: define core framework. > >> >2. SCA-Policy: define policy framework and specific policies. > >> >3. SCA-Bindings: define bindings for SCA services and technologies. > >> >4. SCA-BPEL: define how to write SCA component implementations. > >> >5. SCA-C-C++: develop specs that standardize C and C++ use in SCA. > >> >6. SCA-J: develop specs that standardize Java use in an SCA domain. > >> > > >> >View Document Details: > >> >https://www.ncoic.org/apps/org/workgroup/custreq/document.php?document_ > >id=6733 > >> > > >> >Download Latest Revision of Document: > >> >https://www.ncoic.org/apps/org/workgroup/custreq/download.php/6733/late > >st/SCA%20OASIS%20-%206%20SOA%20TCs%20.pdf > >> > > >> > > >> >PLEASE NOTE: If the above links do not work for you, your email > >application > >> >may be breaking the link into two pieces. You may be able to copy and > >paste > >> >the entire link address into the address field of your web browser. > >> > > >> >-Network Centric Operations Industry Consortium Administration > >> > > >> > > >> >--------------------------------------------------------------------- > >> >To unsubscribe, e-mail: global-custreqs-unsubscribe(a)lists.ncoic.org > >> >For additional commands, e-mail: global-custreqs-help(a)lists.ncoic.org > >-- > >No trees were destroyed in the sending of this message, however, > >a significant number of electrons were terribly inconvenienced. > -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

1 0