servicemix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ge...@apache.org
Subject svn commit: r683534 - /servicemix/sandbox/gertv/smx-sling/README.TXT
Date Thu, 07 Aug 2008 08:05:47 GMT
Author: gertv
Date: Thu Aug  7 01:05:47 2008
New Revision: 683534

URL: http://svn.apache.org/viewvc?rev=683534&view=rev
Log:
Updating the README file once again

Modified:
    servicemix/sandbox/gertv/smx-sling/README.TXT

Modified: servicemix/sandbox/gertv/smx-sling/README.TXT
URL: http://svn.apache.org/viewvc/servicemix/sandbox/gertv/smx-sling/README.TXT?rev=683534&r1=683533&r2=683534&view=diff
==============================================================================
--- servicemix/sandbox/gertv/smx-sling/README.TXT (original)
+++ servicemix/sandbox/gertv/smx-sling/README.TXT Thu Aug  7 01:05:47 2008
@@ -30,14 +30,34 @@
 
 On the auditor...
 - asynchronous archival in JCR instead of blocking message delivery
-  (just put the message metadata in a queue and asynchronously process the queue to send
the messages to JCR)
+  Instead of accessing the JCR directly when exchangeSent() is called, you store the MessageExchange
in a JMS Queue.  This will allow another thread to pick up the message from the queue
+  and store it in the JCR repository -- so the storing of the message exchange no longer
interferes with the ESB throughput
+
 - refactor JCR auditor (with a configurable RepositoryFactory) to separate Sling specific
details from the basic JCR stuff
+  Part of this has already been done, but we should be able to configure the RepositoryFactory
so we can point to another JCR repo when we need to.  This will make the JCR repository more
+  versatile.
+
 - archiving message flows based on the correlation id
+  Messages that belong to the same 'flow' (i.e. have the same correlation id) should be archived
together.  It would be very nice to allow the users to see all the flows and drill down
+  to the exchanges and messages whenever they need to.  
+
 - allow the auditor to be configured to only audit metadata for some exchanges (to allow
usage of stream-based messages)
+  Ideally, we would have a /config node in the repository where all the config data is to
be found.  We can build Sling forms to update the config and use JCR Observation to propagate
this
+  to the sling auditor.  In a normal runtime scenario, it is often enough for users to see
what happened to the message flow, without seeing the actual normalized message content. 
This will
+  allow the use of StreamSources and the like for performance.  Whever the user configures
the Sling /config node, this will change the audit behavior to include all message details.
 
 On the web console...
 - build a dashboard
+  Not sure what has to go there: failed exchanges, throughput, last x exchanges, ... just
things to give users a first entry point in the app.  
+
 - add information about the endpoints themselves
+  If we add an EndpointListener implementation to ServiceMix, we can get feedback on endpoints
being added/removed.  We should have a web page for every endpoint that we can link to from
the exchange
+  pages.  If we could a reverse link -- showing the list of exchanges that passed through
a given endpoint -- that would a great feature!
+
 - make it possible to edit/resend exchanges
+  This is only possible if we can access the JBIContainer either locally or through JMS Flow.
 However, if we audited the the MessageExchange, we can build a form to edit the normalized
message content
+  and send this new content to the endpoint again.
+
 - making the web UI look good
+  no ideas here... anything beyond my web designer skills will be a huge improvement
 



Mime
View raw message