[kepler-dev] web service actor

Bertram Ludaescher ludaesch at sdsc.edu
Thu Apr 1 02:18:18 PST 2004


The good thing about object tokens then is that they can be used,
e.g., to encode "handles" such as Efrat's database connection tokens,
"Grid handles", LSIDs, etc. 

I also see that this my break the MoC (and be a security issue etc.)
but for pragmatic reasons one may still want to use that kind of
mechanism.


Apropos breaking the model of computation: I'm not sure whether I
asked that before, but what are the "recommended" (and maybe not so
recommended) means to "drain" a running process network.

Clearly a PN is easy to "drain" or "starve" from the "head", i.e.,
source side, by slowing down or stopping token production.

For some applications it may be desirable to also slow down or even
stop the computation at an arbitrary point downstream.  I've heard of
this notion of "backpressure" that can be applied in the opposite
direction of the token flow to slow down (and possibly pause/stop) a
process pipeline.

Is such a thing already in Ptolemy II?

Bertram


>>>>> "SAN" == Stephen Andrew Neuendorffer <neuendor at eecs.berkeley.edu> writes:
SAN> 
SAN> One of the things you can do is use an "ObjectToken" to encapsulate an
SAN> arbitrary java object in a token.  Currently, the type system doesn't attempt
SAN> to do much with ObjectToken in terms of static checking, although it could
SAN> easily to Java-style subclass type checking.
SAN> 
SAN> A bigger issue with ObjectToken is that you can pass an object reference
SAN> that can be used for arbitrary "back-channel" communication.  i.e. a reference
SAN> that represents shared memory between the sender and the receiver.  This can
SAN> be used to "break" the model of computation if not used responsibly..
SAN> 
SAN> For instance, Process Networks are formally deterministic, if reads always 
SAN> block on
SAN> empty queues...  If I pass an object token to you and then we use it to 
SAN> communicate
SAN> outside of the Process Network model, then determinism is no longer guaranteed.
SAN> 
SAN> A good rule of thumb is that objects passed in an object token should be 
SAN> "immutable",
SAN> as tokens are, avoiding the back-channel communication issue.
SAN> 
SAN> Steve
SAN> 
SAN> At 09:58 PM 2/25/2004 -0800, Shawn Bowers wrote:
SAN> 
>> I think another issue is if this kind of approach would be considered
>> "circumventing" the Ptolemy type system.  Is it typical for an actor to
>> pass token objects that don't have a corresponding Ptolemy type? And if
>> so, what ramifications might this have on static type checking within
>> Ptolemy and for enabling reusable actors (i.e., removing tight-coupling
>> between actors)?
>> 
>> It must be that the Ptolemy folks have considered the issue of allowing
>> actors to pass arbitrary Java objects, otherwise, why even have a type
>> system?  I guess that missing from the discussion/implementation is
>> bringing it back to the underlying philosophy or design decision at work
>> within Ptolemy concerning tokens, token types, the type lattice, and
>> Ptolemy's static type checking. (I might just be speaking about my own
>> ignorance on the issue here :-)
>> 
>> 
>> Shawn
>> 
>> P.S., I wouldn't necessarily say we were having a "heated" debate; more
>> like a misunderstanding about what the real issue is/was -- at least it
>> wasn't clear to me until the end of the discussion.
>> 
>> 
>> On Wed, 25 Feb 2004, Chad Berkley wrote:
>> 
>> > I just used java types as return objects because it was convenient to do
>> > so at the time.  it's not hard to change.  I'm not sure why you wouldn't
>> > want to use a java object, since soap allows for you to do such a thing.
>> >   If we intend to implement the token passing system that we have talked
>> > about before, i think we are going to need the functionality of a java
>> > object, not just an xsd type.  but we can talk about this. I just wanted
>> > to get something to work with grass/garp.  what did your heated
>> > discussion entail?
>> >
>> > chad
>> >
>> > Bertram Ludaescher wrote:
>> > >
>> > > Chad:
>> > >
>> > > I have some questions regarding the types of data going in and out of
>> > > a web service: In my understanding, web services describe the type of
>> > > their data mostly in XML Schema, and not as Java types.
>> > >
>> > > Since web services can be implemented in different languages, Java,
>> > > C#, PHP, Perl, Python, ... what is the purpose of adding Java types in
>> > > particular?
>> > >
>> > > Wouldn't it be better to use XML Schema types and/or Ptolemy types and
>> > > make them part of the Kepler type system?
>> > >
>> > > We just had a (heated!!) discussion here between Ilkay, Shawn, a local
>> > > web service guru (Jesus) and myself...
>> > >
>> > > Maybe we should have a phone conference on that tomorrow or so...
>> > >
>> > > Bertram
>> > >
>> > >
>> > >>>>>>"CB" == Chad Berkley <berkley at nceas.ucsb.edu> writes:
>> > >>>>>
>> > > CB>
>> > > CB> Hi Ilkay,
>> > > CB> I was just wondering how your progress is going on getting the web
>> > > CB> service actor to return objects (besides strings).  I now have a 
>> bunch
>> > > CB> of web services that make calls to GRASS that I would like to use in
>> > > CB> kepler.  All of these services return the same object
>> > > CB> (GrassReturnObject).  If you want or need some help getting that 
>> actor
>> > > CB> to work, I'd be glad to help.
>> > > CB>
>> > > CB> chad
>> > > CB>
>> > > CB> _______________________________________________
>> > > CB> kepler-dev mailing list
>> > > CB> kepler-dev at ecoinformatics.org
>> > > CB> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>> > > _______________________________________________
>> > > kepler-dev mailing list
>> > > kepler-dev at ecoinformatics.org
>> > > http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>> >
>> >
>> 
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
SAN> 



More information about the Kepler-dev mailing list