[Pipet Devel] DOA'00

[jarl van katwijk]

Hi all,

I just returned from Antwerp, Belgium, where I attended the DOA'00 converance. I
think you people would like to know
the Piper project design is among the most high tech around. In both scientific
and enterprise worlds there're much big
problems and great solutions out of which Piper has a very high fitness. In
other words: We are on the right track :)

Let me address some of the mayor issues that were discussed and are of interest
to the Piper project:

= Integration
    - The need of COST intergration (Commercial of the shelf technology).
Ofcourse this
    term can be replaced by OOST (Open source of the shelf tech.). Is means that
it's
    impossible to create everything from scratch every time, so the availeble
software
    should somehow be easily integrated into a system.
    - Middleware standards.  Personally I dont really care for this and dont see
it of much
    of a problem. Just let the middleware (cq Piper) be transparant to the
applications and
    the problem dont exsists anymore. Maybe I'm being lazy on this one..

= Representation
    - Data representation by models. This is done by models like UML and MOF and

    seems to be a solved problem. Only I dont want this to be touched by Piper,
I think it's
    out of the scope.
    - Functional representation by patterns. This one is very interesting
because it seems
    noone has done a very good job yet. I'm thinking about the XML node
description of
    Piper ofcourse.
    - Service Classification. Piper has two places where this is important: on
the BL->BL
    connection and the PL->Application level. It means that both parties need to
determine
    what protocols\scematics\etc must be used in order to operate together. I
think this is
    a much bigger problems as we though before. But somebody has held a very
good
    presentation about this, so we're not alone :)

= Environment
    - Resource management. Our proposal of the BL->PL design has a alinea
dedicated to
    scheduling, or XML splitting. This spoke about three variants: User defined,
Central
    controll for a user addres space and based upon local reality. This design
seems to be
    very good.
     - Temporary environments. Applications executed by the PL will be part of a
temporary
    system; the environment wont excist anymore once the network has been
executed. This
    again is a much bigger problem as we (or just me?) exspected. At first
though it looks the
    DL will need to do some serieus node versioning together with node history-
and
    configuration tracking.
    - Location problems (naming, lookup). Solutions for a world wide naming
& localisation
    system are numberous, we just need to pick one or combine to get our own
    - Environment isolation. This problem only arises inbetween the lines, the
'normal' solution
    to having seperated node spaces is fixed by physically seperating the
hardware. The Piper
    solution of User Address Spaces is way cleaner.
    - Replication and relocation. Quite complex stuff, but somehow very
attractive to reseach, so
    there're a lot of solutions. There also was a presentation (partially) about
relocalisation by
    sourcecode & M4 macros.
    - Realtime Corba specifications. OH YES, they will be in Corba 3.0! (I met
the persone who
    wrote the Corba 2.0 specs)


bye,
jarl