Coordination Middleware for document-centric applicationsApril 2002

(1)

Coordination Middleware for document-centric applications

April 2002

Paolo Ciancarini Robert Tolksdorf Franco Zambonelli

University of Bologna

Technische Universität Berlin

University of Modena and Reggio Emilia

ciancarini@cs.unibo.it tolk@cs.tu-berlin.de franco.zambonelli@unimo.it

(2)

Motivations



The Internet is "Document Centric"



Document-centric computing models are needed



A document is a communicable data structure



Focus on two key issues:

coordination models and middleware for the engineering of complex content management applications

XML as "The Standard" for passive and active documents

(3)

Documents

Passive document = content + representation

"Formatter programs" like TeX assign rendering behavior to mostly procedural (sometimes declarative) markup

Passive documents have at least two facets:



The abstract view on content (eg. WYSIWYG)



The “concrete” machine-level representation

(4)

Documents



Documents were dependent from devices (a solution: Postscript)



Documents were dependent from applications (a solution: Rich Text Format)



Documents are dependent from the underlying os (think about the document fonts)



Documents are dependent from the browser

(5)

Taxonomy and History

CORBA .net others Object centered

OpenDoc OLE others Binary, closed

Middleware for XML Agents XML Middleware for Agents XML Middleware for XML Agents

Text, open, XML

Document centric others

Middleware

time 2000

1995 1990

(6)

Active documents



Active document = content + structure + behavior



The document itself "knows" how to be handled



Possible perspectives:

Reactive documents: external applications are forced to use the internal behavior to handle documents

Proactive documents: the document/agent can handle itself in autonomy

(Agents = data + behavior + autonomy)

Documents virtuels personnalisables (DVP2002)

http://iasc.enst-bretagne.fr/DVP2002

(7)

Middleware for XML Document Agents



Middleware that offers services for agents that

are specified using XML and

"run'' in an XML environment



Agents live in a completely XML oriented world



Middleware is implemented outside the XML world



Examples: Displets, JXML, Adlets

Text, open, XML

(8)

Displets [Dept. Computer Science, Univ. of Bologna]



General-purpose framework for active documents and for multi-document-agents applications



XML document agents ("Displets") can:

include re-active behaviors related to rendering, printing, be searched..

Include pro-active behaviors to produce animation, generate new documents, search, etc…

coordinate with each other

(9)

The XML Compiler of Displets



- XML document -> DOM tree



- DOM tree -> DOM tree with XSL stylesheet



- The DOM tree -> tree of runnable Java objects



The XML document has become a

document agent!

(10)

Coordinable Displets



Displets can have associated

their own “private” behavior

when on a group the “coordination” behavior enacting coordination laws



Static approach

compiler-based

the document agent and

coordination laws generated at

compile time

no dynamic entering or leaving of groups

(11)

XML Middleware for document Agents



Coordination middleware that exploits XML at the middleware level in itself



Coordination activities of application agents occur and are ruled via

accesses to shared XML information spaces, in which the laws ruling

coordination reside and are enacted



Information space in itself becomes sort of an active document agent



Examples:

XMLSpaces, MARS-X, XMIDDLE, XML Protocol/SOAP

Text, open, XML

(12)

XMLSpaces [TU Berlin]: XML documents as field-data



<?xml version="1.0"?>

<!DOCTYPE address SYSTEM

"address.dtd">

<location>

<city name="Trento"/>

<host>FACOLTÀ DI ECONOMIA</host>

<street name="Via Vigilio Inama"

no="5"/>

</location>

(13)

How to match?



A formal is an object describing an XML document



Can be:

Another document:

in(2001, ?__)

Something else

in(2001, DOCTYPE="address.dtd")



There is a variety of relations that identify XML documents

<?xml version="1.0"?>

<!DOCTYPE address SYSTEM

"address.dtd">

<location>

<city name="Trento"/>

<host>FACOLTÀ DI ECONOMIA</host>

<street name="Via Vigilio Inama"

no="5"/>

</location>

(14)

Multiple matching relations in XMLSpaces

Relation Meaning Tool used

Exact equality Exact textual equality DOM interfaces Restricted Textual equality ignoring

equality comments, PIs, etc. DOM interfaces

DTD Valid towards a DTD XML4J

DOCTYPE Uses specific Doctype name DOM

XPath Fulfills an XPath expression Xalan-Java

XQL Fulfills an XQL expression GMD-IPSI XQL AND Fulfills two matching relations –

NOT Does not fulfill matching relation –

(15)

MARS-X [University of Modena and Reggio Emilia]



A coordination infrastructure for mobile agents

virtual mobility

actual agent mobility

physical (i.e., device) mobility



Local XML dataspaces for mobile agent access

shared by a node (or domain of nodes)

Linda-like (JavaSpaces) interface to XML data

Programmable tuple space model:

coordination laws can be

programmed in Java

i

Linda-like (JavaSpace) interface XML Dataspace

Locally Executing Agents

Reactions: meta-level tuple space Node / Local Domain of Nodes

(16)

MARS-X: Tuple-based Access to the XML Documents



XML entries as JavaSpaces tuples

...

<infoN>

<f1>3</f1>

<f2>foo</f2>

<f3>blah</f3>

<f4>17</f4>

</infoN>

...

<infoN>

...

</infoN>

...

class _infoN extends AbstractEntry {static final URL DTDfile = new URL(“http://mysite/myDTD.dtd”);

public Integer f1;

public String f2;

public String f3;

public Integer f4;}

_infoN t = new _infoN();

t.f1= null; t.f2 = “foo”;

t.f3 = “*bl*”; t.f4 = 17;

myEntry result = space.read

(t, null, NO_WAIT);

...

(17)

XMIDDLE [University College, London]



A Middleware (i.e., a coordination infrastructure) for mobile and ad-hoc networks



The nodes/processes in the network share a global XML data structure



The global data structure is an active document

it includes protocols for handling data reconciliation and data merging

also application specific protocols can be defined

(18)

XMIDDLE: The Architecture



Coordinables are active processes

mobile AND/OR executing on a mobile device



Coordination media as XML tree

possibly replicated (even partially) and shared among processes in the reach



Coordination laws rules modifications to the XML tree

(19)

XMIDDLE: Coordination over the XML Tree



Processes operate and coordinate

with each other by manipulating a shared tree



A disconnected process can continue operating on a replica of the tree



When reconnecting, the global document tree must be

re-constructed in a consistent way

Disconnectio n

of Process A

Process A

Process B

Process A

Process B

Reconnection of Process A with re-conciliation

(20)

Self-contained XML Middleware



Agents are represented as some XML documents as well as

the data they operate on and the laws ruling their coordination activities



Examples: WorkSpaces, XSL, XML Script, ADF

Text, open, XML

(21)

Workspaces [TU Berlin]: XML and XSL only



Documents and worksteps as

XML documents



Workspaces engine is an extended XSL

engine

_Workspaces

engine

<RATING PAPER="3"

SCORE="4"/>

Store Rating exec("Excel")

<RATING PAPER="3"

SCORE="4"/>

Document ^Workspaces

Engine Document

Activity description

(22)

Higher and guarded coordination in workflow graph



AND-SPLIT, OR-SPLIT, AND-JOIN, OR-JOIN as

generative (and destructive) coordination operation



Transitions may also have conditions

accept?

</DECISION>

Handout copies of

papers

Distribute

accept?

</DECISION>

Think and lookup

accept?

</DECISION>

Think

Answer questions

reject

</DECISION>

accept?

</DECISION>

Think and lookup

accept?

</DECISION>

Think

Answer questions

accept

</DECISION>

Collect Collect reviews

<DECISION>...

</DECISION>

<DECISION>...

</DECISION>

(23)

Workspaces



An XML/XSL based workflow system



Workflow graph is split into single steps that are represented as XSL documents

accept?

</DECISION>

Handout copies of

papers

Distribute

accept?

</DECISION>

Think and lookup

accept?

</DECISION>

Think

Answer questions

reject

</DECISION>

accept?

</DECISION>

Think and lookup

accept?

</DECISION>

Think

Answer questions

accept

</DECISION>

Collect Collect reviews

<DECISION>...

</DECISION>

<DECISION>...

</DECISION>

step description

XML document

XML document step

description

XML document

XML document step

description

XML document

(24)

Discussion

 Displets

 suitable for the definition and implementation of document agent apps

 Too static

 MARS-X

 suited for complex coordination patterns to be dynamically defined, in manipulation of shared XML documents by mobile agents

 restricts the application to use Java agents

 XMIDDLE

 suitable for document agents, and seems very suitable for mobility

 possibility of defining coordination laws very limited

 Workspaces

 provides more uniformity

 lacks an explicit support for mobility,

(25)

Goal: Design ideal XML middleware

 directly handling, at the application level, the activities in XML document agents (Displets)

 making coordination activities occur in terms of manipulation of shared XML documents, (MARS-X, XMIDDLE, XMLSpaces)

 flexible to support user-defined XML grammars (XMLSpaces)

 effectively handling mobility and associated issues (XMIDDLE)

 enabling the ruling the coordination activities between

application-level document agents in a dynamic way (MARS-X)

 expressing not only document agents behavior but also the laws ruling their coordination activities in term of XML

(26)

Conclusions



Further consider

Mobility

Coordination models

Embedded systems

Organizational structures



Conclusion:

Taking the "coordination viewpoint" on XML based middleware is again fruitful