[seek-dev] Ptolemy II comments

[Amy Sundermier]

I spent some time reviewing the large PDF document describing Ptolemy II.
These comments are based on that document.  I have not looked at Ptolemy
code so if the document is out of synch with the code will someone let me
know?  Thanks.

Comment #1:  Ptolemy is not a distributed architecture.  There is no
inherent support for distributed components such as web services or
distributed processing.  Since I am currently looking for something to
support integration of web services, this is an issue for my project.  

Comment #2:  Ptolemy seems to have been designed for modeling engineering
designs.  Most of the examples are related to electrical engineering.  In
looking over the framework and modeling language, I came to the conclusion
that this framework would have difficulty modeling software.  The reason is
because there is no clear distinction between classes and instances of
objects being modeled.  In the physical world, objects (for example,
electronic components) do not usually pop into and out of existence.  Yet
this is normal in an object-oriented program.  The Ptolemy documentation
spoke of "mutable models" but that appeared to be a barely supported
concept.  Software modeling requires that the model recognize object
instances and dynamically changing relationships.  It is similar to the
difference between UML class diagrams and UML collaboration diagrams.  A
class diagram does not model a running execution of a program the way a
collaboration diagram can.  I think the modeling language, the framework,
and even the domain models may be impacted if an attempt is made to extend
Ptolemy to handle software modeling.  Has anyone else looked into this issue
in detail?  I've run into this limitation before when I tried to use a
framework for "real world" objects as the basis for a software integration
framework.  There are often design assumptions in such an architecture that
cannot support objects with a lifecycle.

Comment #3:  The Ptolemy framework implements its own typing system, typical
of frameworks that were originally implemented in languages that did not
support reflective access to objects.  Although this is not a bad thing in
and of itself, it complicates the usage of Ptolemy in combination with other
languages and technologies that do support reflective access since for every
new component type you want to support (ie. Java objects, WSDL described
components, etc), you must bridge between the Ptolemy type system and the
component's type system.  

Comment #4:  The MoML language seems very limited and relies heavily upon
the choice of domain model to interpret the meanings of the relationships
between components.  In my opinion, this seems to delegate a lot of the
important semantics of the model to code that is embedded in the domain
model instead of expressing it explicitly in the modeling language.  It does
make me wonder if the domain models could be used independently of the
Ptolemy framework and modeling language, however.  I have not explored the
code in order to figure that out.

Comment #5:  I found a comment in the documentation that said MoML is based
upon a DTD, not an XML Schema, therefore namespaces are not supported.  XML
elements passed between components may come into conflict with MoML
elements, according to the documentation.  Has anyone looked into the
difficulties this may cause?  EML is a very large schema and seems bound to
cause conflicts with any tool that doesn't support namespaces.

Comment #6:  Our needs for a pipeline processor (or whatever you want to
call it) include the ability to invoke the processor as a distributed
component itself in order to process a pipeline constructed by an
application.  Ptolemy seems to be very centered around the use of a
standalone graphical modeling tool in order to execute MoML.  Does the
execution engine for MoML exist as an independent entity that can be invoked
from a web application, or is it embedded within the graphical tool?

Comment #7:  I believe that if I wanted to try to use any of the features of
Ptolemy, I would be most interested in the domain model code.  The semantics
of how the models interpret relationships between components for different
notions of time appears to be the most useful contribution of the framework,
in my opinion.  However, I'm not sure our applications require time-oriented
modeling...we're still looking at our requirements.  

So I have a question for the Seek-dev group that has obviously spent more
time working with Ptolemy than my brief review... What features of the
Ptolemy architecture were considered "must have"?  Or is this still under
investigation?

I am very interested in knowing if I have any misconceptions about Ptolemy.
Please let me know if you believe my comments are in error.

I am still evaluating BPEL4WS, a language specifically designed for
integrating web services.  I downloaded an execution engine from IBM
Alphaworks (BPWS4J) and I'm planning to try it out.  It has a graphical tool
for describing processes.  I want to verify that BPWS4J is capable of
supporting an XML Schema as complicated as EML.  I also want to see if I can
create a process that can be called from within one of my existing web
applications to integrate some web services I've already written.  I'll let
you know the result of my experiences.  

Amy Sundermier
Center for Environmental Studies
Arizona State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-dev/attachments/20030709/54c18888/attachment.htm