On Sun, Jan 15, 2012 at 9:17 AM, Mattmann, Chris A (388J) < [email protected]> wrote:
> Hi BW, > > On Jan 14, 2012, at 8:06 PM, B W wrote: > > >> No-where really -- it's just that we don't have an explicit > representation > >> of an > >> architecture object in Apache OODT proper, as it existed in GLIDE (being > >> built on top of PRISM-MW it afforded us the ability for architectural > >> introspection, etc.) > >> > >> You mean the the tight coupling is a real characteristic but conceptual > at > > the messaging component that does not really exists as a concrete > artifact? > > Yep, I think that's the key -- it's more conceptual in nature, but does > exist > in the form of whatever messaging layer substrate is chosen. At its heart > Apache OODT is loosely coupled, IMHO, as it leverages the client/server > architecture, which allows for e.g., dynamic additions of new clients, and > servers; servers don't need to know which clients are connecting to them; > clients need only the end points of the servers; clients and servers can > go away, etc. > > Ok. Great! Thx. But, no matter what concrete message layer substrate we choose the synchronous nature imposed by OODT's architecture still exists. Which I guess highlights the importance of advanced planning of reusable scientific work flows that can be automated. This is a mitigation tactic of the synchronous nature through staging and checkpoints for fault tolerance and recovery? Cheers, > Chris > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >
