nnexai / xml-broker Goto Github PK

There seems to be a problem with some of the dynamic web-pages generated from the example apps. In most cases a request will have the type text/plain (which will not be rendered correctly by browsers) even though setContentType("text/html") is used.

Allow services to register and unregister for events dynamically (while the servlet is running).

Possible ways:

• inline -- register and unregister are events the broker itself subscribed for
• restful -- use html put / delete

Restful is preferred since this way other services may not subscribe to the registration events and thus gain information about other services.

Need a secure way to filter Expressions. (Could be misused to load external XML files etc..)

Error in XPathFilter -> deliver (should proxy recieved domtree)

Write build-scripts using ant for all contained subprojects

The Broker should not remove CDATA-Tags from given xml document.. this will most certainly lead to parse-errors at the services if not handled. A passable way to fix this is to use MultiXMLRootFilter.

Also the XPathFilter needs to be fixed.. it should also recieve the String representation of the given Document. The query should only contain a filter-expression meaning for "//event[@id=1]" it should be written as "@id=1" returning the original string if the query would return an element (this should be a bit faster, too ^^)

PUT and DELETE should work with
http:///<...>/XMLBroker/

the uri should be independant of eventtype etc!

(need to rework Service-Map)

Currently Post-Requests are handled as following:
/-> Deliver1
Req1 --> Parser --> Filter --> ... --> HttpDelivery --> Deliver2
x-> Deliver3
Req2 --> Parser --> Filter --> ... --> HttpDelivery --> Deliver4
-> Deliver5

This way every Stage needs to be fully thread-safe. One way to loosen this Requirement would be to multiplex events into a single stream (BlockingLinkedList?). Some Benchmarks are needed to decide for the right design

Add a pool for connections that should be held open for a long time. This should be helpful for high-throughput.

During registration a service should be able to give a hint, if it supports streaming xml-events and allows the connection to stay open for a (long) period of time.

e.g <HTTPService event="log" url="http://..." streaming="true"/>

Delivery through netty is broken unreliable. The Speed-Test shows that under high pressure netty will drop some events (most likely this has to do with wrong synchronisation in the delivery class!).

Need a way to measure throughput etc... Currently a combination of a Stream-injection tool (starts the brokers parser directly without the overhead of sending the file beforehand) and a service that collects all messages is used to generate a simple graph + table... need a way to automate this progress...