1 2 Previous Next 20 Replies Latest reply on Dec 3, 2010 9:50 AM by burmanm Go to original post
      • 15. Re: JCRMessageStoreImpl store only message body?
        jackalista

        I am looking at the MessageStore and am interested in a browse-able, query-able interface for the store, and came across this and another thread talking about using JCR implemetations as either the store itself or as merely a way to provide JCR functionality with the message being stored elsewhere (I'm assuming the actual store would still be inm the DB in this case?).

         

        I did find the JCRMessageStoreImpl class, I'm not familiar with the code per se but it looks like the payload is being extracted so I'd guess that the entire message is not being stored, is this correct?  That also seems to be the status put forth by a few JIRA entries (https://jira.jboss.org/browse/JBESB-1769, https://jira.jboss.org/browse/JBESB-2205, https://jira.jboss.org/browse/MODE-119 & https://jira.jboss.org/browse/MODE-280) and the consensus seems to be that the use of this JCR technology for the MessageStore will not be as useful as one might want without the entire message being stored.

         

        Is this the current status of this stuff and am I understanding the situation correctly?  So I'm guessing that this does not provide a way to browse and query a MessageStore?  Long story short, I'm looking for an audit oriented MessageStore with as high level an API as possible, and not sure what functinality exists and where it's headed, I'd like to leverage the work you guys are doing if it makes sense but I am not sure what the best current thinking is on this and am searching this stuff to try to figure it out.  It kind of looks like this stuff is either a dead end, or perhaps is slated for dev sometime in the future but I can't tell which.

         

        Can anyone advise on the best currently available MessageStore functionality for browsing and querying the MessageStore and any other needed functionality to provide audit logging features?  Or, if appropriate, can you share what road map exists so that we can use what's there now and remain properly positioned to be ready to take advanatage of further features as they come online?  Thanks...

        • 16. Re: JCRMessageStoreImpl store only message body?
          burmanm

          I didn't find JCR to be correct way to handle this issue, so I personally created a new RDBMS based system, where we store the message's status and different payloads in several stages of the message. For tracking issues, we also modified the Actions and used filters to store auditlog from every entry point and exit point and everytime we change the message's properties.

           

          However, for the message store, the problem with relation database is storing all the attributes in reloadable format. I created and EAV-store to store all the attributes in few different formats (Long, String, Date ..) to the database as the message's properties. It's not perfect solution (it's difficult to store JPA Entitys this way unfortunately), but we do have a lot of information and track the messages.

           

          Basic idea if this:

           

          message-table (store message uuid etc stuff here)

          -> n * message_properties

          -> Store all the payloads and attachments as documents

              -> all the documents have 0-n binaries associated to them

              -> attachments have 0-n properties stored for them

           

          That's simplified example of the message store. It's one of the features which I'd really want to be more complex in the actual ESB distribution, since we also require a queryable datastore. Now we've built a webapp to list and search this message store.

          • 17. Re: JCRMessageStoreImpl store only message body?
            jackalista

            Thanks Michael.  Yes, I'd like to see the ESB dist take this up and provide a more robust and fully featured store as well.  We have unclear needs at this time, but do need basic audit logging.  What facilities exist in the ESB dist for querying, lsiting and searching the store, do you know?  I have not found much on that.  I would porefer to do something simple for now and be positioned to leverage future ehnancements to the ESB dist MessageStore but am not clear on the road map, schedule and features, both that exist now and are planned for the future.  Do you know about any of this?

            • 18. Re: JCRMessageStoreImpl store only message body?
              burmanm

              Hi, I'm not afraid there isn't much currently which you could use for auditing purposes for searching and such. The auditlog Filters included in the ESB only print to the log, and you would have to parse those to get something useful. I'd recommend creating your own, I don't think there's even any plans to create something 'universally' useful. If there is, I'll gladly commit something (with annotations on the actions, it should be possible to use aspectJ or something to catch action processing, but I haven't tried it).

              • 19. Re: JCRMessageStoreImpl store only message body?
                jackalista

                Hey Michael, thanks for the note.  Can you give me a pointer to these auditlog filters?  I haven't seen that.  Hmmm, so you think there are no plans to build even administrative interfaces to this functionality or anything?  That seems... odd.  Do you know, by any chance, what happened to this JCR effort?  I traced it through various discussion threads and JIRA tickets but it looks like it hasn't been even discussed in a couple years though I did find some src in the ESB dist.  There is also the issue with redundant Base64 encoding making the messages unreadable in the DB, in the default impl, and it appeared, from what I read, that somebody removed the extra encoding of the (XML) message itself applied by the default DB impl but that doing so hit a build problem that occurred on some platform, but not on the Mac OS X platform of the original author (maybe Mark Little?  I can't remember who it was for sure) and it appears that this was also never resolved.  I am told by our contacts @ JBoss that this is a key product in the SOA platform, and that there are plans for continuing development and that wood is being put behind this "arrow" so to speak but I sure would like to know specifics around what is planned, in what priority and on what schedule, even in general terms.  Do you have any idea about any of that?  My current needs are minimal, but I can see that changing (growing) as time progresses; if JBoss isn't going to put effort into this product, however, it may be that this is the wrong bus to get involved with which would be sad.  Any clue about this stuff?  Thanks for your responses, BTW, they are much appreciated!

                • 20. Re: JCRMessageStoreImpl store only message body?
                  burmanm

                  Hi, sorry for not answering quicker. For development plans, I assume that currently they're focusing on JBoss ESB 5.0 branch, which I guess should be partly at least a rewrite. There isn't much information released unfortunately.

                   

                  For current product, the DBImpl does work (at least for redelivering purposes) so I don't know if it's broken somewhere. At least with SQLServer it does (no idea of MacOS, I only use Windows/AIX). The TraceFilter is in package org.jboss.internal.soa.esb.message.filter.TraceFilter and has following comment on it:

                   

                  * This input/output filter can be used for message tracing. It is enabled on a global
                  * basis and assumes that each message is uniquely identified by the MessageID in the
                  * header: otherwise tracing specific messages is impossible to guarantee.

                   

                  Basically what it does is when something enters a gateway or exits it, it prints message.getHeader() to log. Not much, but gives you a basic understanding of what it could do.

                   

                  I agree that it's pretty sad what sort of activity is present here at the moment for some issues. Basic issues get replies, but it looks like no one is interested in sharing advanced features or things they've sort out (problems etc).

                   

                  For basic logging purposes, what you could do is make the filter print that information to database and make one column as "message_id". That way you could trace whenever it has changed Service inside your ESB and find them from DB. That's quick to do.

                  1 2 Previous Next