The XLeges System: PeertoPeer for Legislative Document Exchange

1
The X-Leges SystemPeer-to-Peer for Legislative
Document Exchange

• Massimo Mecella
• Dipartimento di Informatica e Sistemistica
• Università di Roma LA SAPIENZA
• mecella_at_dis.uniroma1.it
• Joint work with CNIPA (Luca De Santis Caterina
  Lupo)

2
The X-Leges Context

• A project inside the E-Leges framework
• Involving the Italian PAs in charge of
  legislative document management
• Presidency of the Republic
• Senate
• Chamber of Deputies
• Office of the Prime Minister
• Ministry of Justice
• National Printing Office

3
X-Leges - Requirements (1)

• Management of the entire legislative documents
  life cycle, to be integrated with existing
  (legacy) systems
• Support for the cooperative processes that
  produce laws and legislative documents
• Exchange of documents
• Exchange of added-value information
• Information access/notifications

4
X-Leges - Requirements (2)

• more a groupware than a workflow management
  system
• Users maintain the full control over their
  activities, the system is not proactive towards
  operators
• The process is built a posteriori, not
  preexistent process schema
• Distributed architecture, to preserve single
  administrations autonomy and technological/organi
  zational independence

5
X-Leges - Requirements (3)

• Standard technologies and multi-platform
• Document exchanges on top of certified e-mail
• Support for alarms and notifications

6
The Italian Process
7
An Intuition (1)
directory

• The cooperative process originating the law
  produces a directory
• Each step of the process adds a folder to the
  directory
• Several objects are in a folder, e.g., the text
  of the law, additional documents, etc., referred
  to as document objects

1..N
folder
1..N
document objects
8
An Intuition (2)

• At each step, only the recently added folder is
  exchanged
• through the exchange interface
• When some user is willing to access the directory
  (and the history of the corresponding process),
  all involved administrations are queried
• through the query interface

9
What Is Exchanged ?(Structure of the Folder)

• Each folder consists of 3 elements
• proper document objects
• All the documents that are currently manually
  exchanged in hard copies - motorbike-ware
• meta-information (additional document objects)
• They depends on the process, on the specific
  steps, etc.Their exchange is the main
  added-value of the system

10
What Is Exchanged ?(Structure of the Folder)

• Workflow data, to reconstruct the process
• Identifier of process/directory (URN)
• Identifier of step/folder (URN)
• Exchange timestamp
• Sender
• Receiver
• Titles, ids (URN) and references of the exchanged
  proper document objects
• References to the exchanged additional document
  objects

11
Exchange Format(Structure of the Folder)

• Text of laws in XML, conform to the NIR standard
• Proper document objects in any format (PDF, MS
  Word, images, etc.)
• Additional document objects in XML, conform to
  specific XSD (defined ad hoc)
• Process data in XML, conform to a specific XSD

12
Exchange Format(Structure of the Folder)
13
Architecture (1)

• pure peer-to-peer
• Each administration deploys an equivalent
  instance of the peer X-Leges
• The system is given by the union of all the peer
  X-Leges
• Interaction roles are not fixed in some
  scenarios a peer is client, in others the same
  peer acts as server

14
Architecture (2)
15
Anatomy of a Peer X-Leges (1)
16
Anatomy of a Peer X-Leges (2)

• Database X-Leges
• Application Logic
• Master and façade of all other components
• Offers a public API (both request/reply and
  listeners/callbacks)
• User interface
• Sending and receiving (triggered by users), with
  automatic completion of the data if made
  accessible by the back-end system

17
Anatomy of a Peer X-Leges (3)

• Web Service
• Information to other peers information in order
  to reconstruct the directory
• Subscriptions/notifications
• Exchange Adapter
• Interface towards the certified e-mail system

18
Anatomy of a Peer X-Leges (4)

• Adapter
• Integration with the back-end system
• When a folder is sent, in order to access
  possible information already stored in the
  back-end system, and to notify it the event
• When a folder arrives, in order to notify the
  event and let the back-end system access the new
  information
• Each time the back-end system needs to access
  information in X-Leges (and vice-versa)

19
Anatomy of a Peer X-Leges (5)

• Loosely coupled (read-only)
• The database X-Leges is never updated triggered
  by the back-end
• X-Leges always acts as a client (it updates
  itself on its own initiative)
• The back-end system is never updated by X-Leges,
  it is notified and then, the back-end, according
  to its own business logic, accesses information
  and possibly update itself

20
Anatomy of a Peer X-Leges (6)

• Event/alarm subscription database
• Each peer hosts an identical copy of it
• The different copies are synchronized through the
  Web Service
• Event alarm steward
• Users subscribe to their peer, that subscribes to
  the steward notifications flow admin-2-admin,
  then admin-2-users
• U _at_ A is interested in E (defined _at_ B, i.e., B is
  steward)
• U subscribes at A, and A subscribes at B
• When the application logic of B raises the event,
  a notification is sent to A through the Web
  Service
• The application logic of A verifies which users
  are subscribed and notifies U

21
Interaction Scenarios (1)(Sending)
22
Interaction Scenarios (2)(Receiving)
23
Interaction Scenarios (3)(Process/directory
reconstruction)
24
Interaction Scenarios (4)(Event/allarm
management)
25
Tecnologies

• Database X-Leges
• RDBMS with XML extensions
• Event/allarm Subscription Database
• either RBMS or PS tools
• Application Logic Exchange Adapter Web
  Service
• J2EE application server
• User Interface
• HTML-based

26
Conclusions

• Very innovative system, wrt. the actual status of
  the involved organizations
• Currently the feasibility study and the
  architectural design have been completed
• Next 6 8 months for development
• Operative at beginning 2006