I was wondering whether you meant "divided single apps" by "parameter sweep types of apps." If that is the case, I don't think that it's less common than "multiple coupled apps," and that it's a rare application. I think that it's in fact the kind of applications that will perhaps benefit most from exploiting the Grid with the current limitations in network bandwidth and latercy between WAN interconnections. As we see in case of Condor, Nimrod and other systems. there are many existing systems aiming at tackling "parameter sweep apps." In addition, we might be able to consider a collection of single job submitted from different job managers to EPS/CSG to be a kind (?) of parameter sweep apps that EPS/CSG needs to make mapping plans. In brief, the point I am trying to make here is that when it comes to the design of EPS/CSG interface and protocol, having the matching/scheduling of parameter sweep type of apps (i.e., a set of independent tasks of job type) in mind is important as well. Soonwook -----Original Message----- From: owner-ogsa-rss-wg@ggf.org [mailto:owner-ogsa-rss-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Wednesday, December 14, 2005 8:57 PM To: Karl Czajkowski Cc: ogsa-wg@ggf.org; ogsa-rss-wg@ggf.org Subject: Re: [ogsa-wg] Re: [ogsa-rss-wg] Re:[RSS Architecture Discussion] Karl Czajkowski wrote:
However, I think you would quickly want a more rich resource language extension---beyond JSDL v1---where you could describe network connectivity requirements (possibly hierarchically) and heterogeneous resource requirements. For example, describing a job where you need a certain number of "large memory" nodes with a good interconnect, a certain number of "fast CPU" nodes with a separate good interconnect, and a less stringent WAN connection between the two node sets for some coupled numerical code. This is definitely beyond the scope of the JSDL v1 resource language, though a nice extended language could encapsulate multiple v1 resource clauses, one for each homogeneous node set...
That's the sort of situation I'd prefer to describe as two (or more) applications within a workflow with some kind of coupling constraint, rather than as a single distributed app. In any case, the "multiple coupled apps" case is probably going to be more common than the "divided single app" case, simply because it is a rare application that can be chopped apart that way without horrible performance penalties. Apart from this clarification, (I think) I agree with the rest of what you say. (The OGSA-RSS-WG is not going to tackle Workflow Language problem, but it must be done. I'm not at all sure that BPEL is the answer, but half the problem is finding recent versions of the BPEL spec; the only readable one I've ever seen was obviously not powerful enough and does not seem to be what people are using these days anyway. But this a topic for some other group/time.) Donal.