xmlBlaster.org design issues

xmlBlaster is suitable for a typical client/server message based application
where the clients need instant notification about changes in the system.

xmlBlaster gets its name from blasting XML out in the world.
Access control list can be achieved through QOS tags.

Which CORBA POA Policy is used?

The xmlBlaster implements the one thread per request policy.

The server should be able to have several thousands of clients connected.
Therefore the One Thread per Client policy wasn't used.
Many operating systems doesn't handle thousands of threads very well.

The problem to recognize a client again is resolved using a unique server IOR for every client, allowing the server to determine the client thru its calling IOR.
These unique IORs are mapped to the same POA servant with the use of the MULTIPLE_ID POA policy.

Performance issues

The different CORBA IDL methods have different performance contraints:  

Publish/Subscribe Method Perfomance Requirement Comment
publish() high A ticker may feed every second new data
The Ticker should use the <key oid=""> for identifying the message
The xmlBlaster should have a quick lookup for key-oid (Map)
get() high For examples many client over internet/intranet
by manual invokation (e.g. a mouse click by a user)
The get may use complicated query syntax (SQL,XQL,XSL,REGEX)
subscribe() medium Usually a subscribe() is not invoked too often, it is invoked normally
by manual invokation (e.g. a mouse click by a user)
The subscribe may use complicated query syntax (SQL,XQL,XSL,REGEX)
unsubscribe() medium see subscribe()
erase() low Erasing a Message completly is usually seldom
 

None of the above should require linear search.
 

Querying the XmlKey

To allow performant parameter lookup, the XmlKey is organized with indexing parameters in hierarchical manners.

It is the responsibility of the clients to agree on a hierarchical indexing schema,
for example the following two XmlKeys of two MsgUnits have similar XML tags:
Note that the data itself (content) is not shown

   <key oid="Number1">
      <Airport icao="EDDI">
        <Runway id="1">
           <WindVeloc w_id="2">
           </WindVeloc>
        </Runway>
      </Airport>
   </key>

   


   <key oid="Number2">
      <Airport icao="EDDI">
         <Runway id="1">
           <WindVeloc w_id="1">
           </WindVeloc>
         </Runway>
      </Airport>
   </key>

The XmlBlaster could than reorganize the hierarchy for performant lookup:

      <Airport icao="EDDI">
        <Runway id="1">
           <WindVeloc w_id="2" oid_reference="Number1">
           </WindVeloc>
           <WindVeloc w_id="1" oid_reference="Number2">
           </WindVeloc>
        </Runway>
      </Airport>

The 

oid_reference
is added by xmlBlaster during DOM reorganizing,
to find the original message unit. Performance comparison: