Sending received messages to a JMS Queue

[Aaron Walker]

copied to the group for reference....

Gustav

Yes at runtime. You can override the default values by adding properties to a file called JENTRATA_HOME/conf/covus.conf 

Properties can be specified in the form of ${property.name:defaultValue} within plugin.xml and components xml

I remember one other thing I've changed is the plugin classloader. You can add jars to a lib folder under plugin folder and you just specify this folder in the plugin xml and it will load all the jars in this folder. The jms and ebms plugin are examples of how to use this.

BTW I've cc'ed this to the jentrata google group as I think this discussion would be useful for others

cheers

Aaron

Hi Aaron,

Regarding 4), is this at runtime or at compiletime? If runtime, where is the mechanism that reads the properties from System-properties/external propertyfile?

Regards,
Gustav

Gustav,

I'm in the process of writing a blog post which covers the differences between Hermes and Jentrata Keep an eye on http://jentrata.org/blog

To summarise the changes so far are:

1) Maven'ized the build with a comprehensive pom 

2) added maven assembly to build a tomcat deployable distribution 

3) added source code for the missing test code to make test code compile 

4) added support for system property variable replacement in plugin and config files 

5) added plugin to support using JMS to route messages to and from the gateway (JMS Outbound Support) 

6) add support to ebms classloader to load all jar from a given directory and put jars in plugin/lib dir 

7) added extension-point in ebms plugin for JMS support 

8) added support for ebxml ping including support for displaying them in the UI 

9) inbound message payload validation (only xml payloads and single schema) 10) Basic JMS inbound support, currently routes payload to a single queue

Beyond that lies the Jentrata road map, with some enhancements underway and many planned.

If you want details of changes at the code level you can take a look at the commit history on github https://github.com/jentrata/jentrata-msh/commits/master

My original commit really only contained maven build and project restructure the original code was pretty much left untouched.

In terms of release dates I'm looking for a release around the end of August but we have the current build of Jentrata in production without issue.

I would be keen to know what changes you've made to Hermes? I'm looking at building an open and healthy community and giving Hermes users a path forward which they haven't really had in the past certainly not one which they could get involved with.

If you wanna chat sometime I'm often in the #jentrata IRC channel on freenode.

cheers

Aaron

Btw Aaron, at what time do you think the code-base will be "release-ready"?

Can I find any information on what adaptations you have made of the Hermes code-base on your webpages?


Regards,
Gustav

Hi Aaron,

The requirement is that the message should be delivered even if the listener-integration temporarily is down. So that would mean some sort of retry-functionality. However, I am not sure how it should handle several listeners where only the last one fails...

Regards,
Gustav

Hey Gustav,

Glad to hear you were able to build the code, maven build was the first thing I did.... I'm not a fan of ant builds :)

For inbound messages you mean right? We haven't yet put any handling of failed inbound messages.  As in inbound message payloads that failed to get sent via JMS. This only a problem if your JMS messaging system is down. What is your requirement for this feature?

We have worked around this current limitation by embedding ActiveMQ in the same tomcat instance as the gateway and using a ActiveMQ broker network to communicate with our backend ESB.

I  am planning to implement this feature. In fact the current inbound JMS handling isn't ideal and I want to rework it to make it a more general solution which would include making it reliable.

If you want you can raise a enhancement request on our issue tracker http://www.assembla.com/spaces/jentrata/tickets. You need to sign-up and then watch the project to be able to create tickets

Now the source is up on github and if you need this feature ASAP feel free implement it and send me a pull request Jentrata is a true open source project and we welcome all the help we can get :)

If you have any issues please don't hesitate to contact me as I keen to grow the Jentrata community. 

cheers

On 04/07/2011, at 9:04 PM, Gustav Karlsson wrote:

Hi Aaron,

Thank you for the quick and interesting response!

I have cloned the repo and have managed to properly build it. Very nice that you have converted it into a Maven build. We have it on our wishlist, but it is unfortunately not prioritized.

However, I cannot see that you have done anything about the reliability of the ebms listener-mechanism?

public void execute() throws Exception {
        try {
            MessageDAO messageDAO = (MessageDAO) EbmsProcessor.core.dao
                    .createDAO(MessageDAO.class);
            message.setStatus(MessageClassifier.INTERNAL_STATUS_PROCESSED);
            message.setStatusDescription("Message is processed");
            messageDAO.updateMessage(message);

            InboxDAO inboxDAO = (InboxDAO) EbmsProcessor.core.dao
                    .createDAO(InboxDAO.class);
            InboxDVO inboxDVO = (InboxDVO) inboxDAO.createDVO();
            inboxDVO.setMessageId(message.getMessageId());
            inboxDVO.setOrderNo(nextOrderNo);
            inboxDAO.create(inboxDVO);
           
            fireEvent();

            EbmsProcessor.core.log.info("Ebxml Message ("
                    + message.getMessageId()
                    + ") is stored in inbox with order number: " + nextOrderNo);
        } catch (DAOException e) {
            EbmsProcessor.core.log
                    .error("Error in storing message to inbox", e);
            throw new DeliveryException("Error in storing message to inbox", e);
        }
    }

It seems to me that if the inboxDAO or one of the listeners fails, the message listeners will never be notified?

Regards,
Gustav

Gustav,

I would suggest checking out http://jentrata.org basically Jentrata is a fork of Hermes and it currently has JMS support (only ActiveMQ at this stage but I'm working on making configurable)

Jentrata is design to be a true open source B2B Gateway in that we want to build an active community behind the project. Also the company I work for will be providing commercial support for Jentrata

All the code for Jentrata is up on github (https://github.com/jentrata/jentrata-msh) which you can build from source or we have a link to download a current build.

We haven't yet got a release build yet but the current code based in pretty stable (as in we have it running in Production for a number of customers). Also you can now easily track what has changed via the github repository.

We are currently working on getting documentation up to scratch but if you have any specific question you can email me directly or preferably via the jentrata mailing list (http://groups.google.com/group/jentrata)

I'm also often on the jentrata IRC channel which is #jentrata on irc.freenode.net

cheers

On 04/07/2011, at 4:14 PM, Gustav Karlsson wrote:

Hi Aaron,

We are currently using the push-mechanism in the Hermes2 beta version. I have however noticed that the push-solution is not 100% reliable. In an error occurs in one of the listeners, the event will never be fired for that message. Or am I missing something? Have you found a solution to this?

Regards,
Gustav

Gustav,

It's already on github but in a private repo which I'll make public when it's ready....

yes I mean the hermes google group

The company I work for is looking at the possibility of providing commercial support for the project.

cheers

Aaron

On 09/05/2011, at 10:13 PM, Gustav Karlsson wrote:

Hi Aaron,

Ok, good to know. We are investigating the possibility of using Hermes2 as our ebMS message broker instead of expensive commercial alternatives. We will also have some need of modifying the source to accommodate some of our requirements. Have you considered using github for hosting a fork?

Is the hermes mailing lists you refer to the same as the googlegroups list?


Regards,
Gustav

Gustav,

Yes I've been using the beta in production but I have made a number of changes mainly to support JMS plus the addition of payload validation framework.

I'm actually considering creating a fork of whole project.

I'm done a major refactoring of the build system plus some minor clean-up of the code base.

I'm just trying to get a hold of some of the missing code for some of the dependencies  from the original authors. I've currently stubbed out a bunch of code to get everything including the test code to compile.

Keep an eye on the hermes mailing list as I'll send a message once it's ready to go.

I'm keen to try and build a community to continue the development of the project.

cheers

Aaron

On 09/05/2011, at 9:14 PM, Gustav Karlsson wrote:

Hi Aaron,

Thanks for the quick reply!

Just to clarify, have you been using the beta in production as well?

And if I may ask, what were the plugins you were considering open sourcing?

Regards,
Gustav

Gustav,

Yeah it's based on a newer release http://community.cecid.hku.hk/download/beta/hermes2_src_20100331.zip

It is a beta but it's pretty stable have been using for the last few months without issue.

cheers

On 09/05/2011, at 8:49 PM, gustav80 wrote:

Hi Aaron,

I have a similar problem, but I cannot find the class
EbmsEventListener in the H2o source code. Is this a new addition to
the source?

Regards,
Gustav

Add an EbmsEventListener implementation to the ebms.module.event.xml

it might look something like

<?xml version="1.0" encoding="UTF-8"?>

<module id="eventModule" name="Corvus ebMSEventModule" version="1.0">

        <component id="messageListenerJMSClient" name="MessagelistenerJMS Client">

                <class>hk.hku.cecid.ebms.spa.client.jms.MessageListenerJMSClient</class>

                <parameter name="connectionUrl"    value="${jentrata.activemq.connectionFactoryUrl:vm://localhost?broker.persistent=false}" />

                <parameter name="queueName"        value="${jentrata.activemq.inbound.queue:Ebms.Inbound}" />

        </component>

</module>

we are using ActiveMQ as our JMS provider

The hk.hku.cecid.ebms.spa.client.jms.MessageListenerJMSClient class looks something like

public class MessageListenerJMSClient extends EbmsEventListener {

..........

        @Override

        public void init() {

                connectionFactory = new ActiveMQConnectionFactory(getConnectionUrl());

        }

......

        @Override

        public void messageReceived(EbxmlMessage requestMessage) {

                try {

                        initialiseJMSConnection();

                        sendMessageToQueue(requestMessage);

                        closeSession();

                } catch (JMSException e) {

                        EbmsProcessor.core.log.error(e);

                }

        }

.......

        //we only ever have a single attachement

        private void sendMessageToQueue(EbxmlMessage requestMessage)

                        throws JMSException {

                TextMessage textMessage = session.createTextMessage();

                textMessage.setStringProperty(MSG_PROPERTY_CPA_ID,requestMessage.getCpaId());

                textMessage.setStringProperty(MSG_PROPERTY_SERVICE,     requestMessage.getService());

                textMessage.setStringProperty(MSG_PROPERTY_ACTION,requestMessage.getAction());

                textMessage.setStringProperty(MSG_PROPERTY_CONV_ID,     requestMessage.getConversationId());

                if (requestMessage.getFromPartyIds().hasNext()) {

                        PartyId partyId = (PartyId) requestMessage.getFromPartyIds().next();

                        textMessage.setStringProperty(MSG_PROPERTY_PARTY_ID,partyId.getId());

                        textMessage.setStringProperty(MSG_PROPERTY_PARTY_TYPE,  partyId.getType());

                }

                textMessage.setStringProperty(MSG_PROPERTY_SERVICE_TYPE,requestMessage.getServiceType());

                SOAPMessage msg = requestMessage.getSOAPMessage();

                Iterator it = msg.getAttachments();

                while (it.hasNext()) {

                        Object o = it.next();

                        AttachmentPart attachment = (AttachmentPart) o;

                        try {

                                textMessage.setText(convertStreamToString(attachment.getRawContent()));

                        } catch (SOAPException e) {

                                EbmsProcessor.core.log.error("SOAP exception", e);

                        }

                        catch (IOException e) {

                                EbmsProcessor.core.log.error("IO exception", e);

                        }

                }

                producer.send(textMessage);

        }

}

This should get you started....

I'm working on a number of custom plugins with JMS Inbound and outbound support being one of them. The plan is to open source them in the coming weeks.....

Let me know if you interested and I'll shoot you an email when it's ready....

cheers

Aaron

On 28/04/2011, at 12:04 PM, Lester wrote:

Hi,

From the documentation of Hermes B2B i can see its possible to receive

the list of message ids and then download each messge payload. This is

a poll mechanism. Do we have api's exposed to do the following;

1. Either have a listner that triggers on the arrival of a new message

in the hermes b2b

2. On the arrival of new messages the messages are pushed to a JMS

Queue.

Let me know if such possibilities exist with the current Hermes 2.0

distribution.

Regards,

-Lester

[Aaron]

Gustav,

This commit shows most of the changes
https://github.com/jentrata/jentrata-msh/commit/61d7ec9389dedeb048d36bb6b255151c7b4f0152

This one for support in components
https://github.com/jentrata/jentrata-msh/commit/c1984ef09709091e58abe6ab4f05bfc8e937d2c4

But basically the commits in the period from the 2011-03-24 till the
2011-03-29 see https://github.com/jentrata/jentrata-msh/commits/master?page=3

cheers

Aaron

On Jul 13, 10:03 pm, Aaron Walker <aaronpwal...@gmail.com> wrote:
> copied to the group for reference....
>
>
>
>
>
>
>
>
>
> >> Gustav
>
> >> Yes at runtime. You can override the default values by adding properties to a file called JENTRATA_HOME/conf/covus.conf
>
> >> Properties can be specified in the form of ${property.name:defaultValue} within plugin.xml and components xml
>
> >> I remember one other thing I've changed is the plugin classloader. You can add jars to a lib folder under plugin folder and you just specify this folder in the plugin xml and it will load all the jars in this folder. The jms and ebms plugin are examples of how to use this.
>
> >> BTW I've cc'ed this to the jentrata google group as I think this discussion would be useful for others
>
> >> cheers
>
> >> Aaron
>
> >> Hi Aaron,
>
> >> Regarding 4), is this at runtime or at compiletime? If runtime, where is the mechanism that reads the properties from System-properties/external propertyfile?
>
> >> Regards,
> >> Gustav
>
> >> Gustav,
>

> >> I'm in the process of writing a blog post which covers the differences between Hermes and Jentrata Keep an eye onhttp://jentrata.org/blog

>
> >> To summarise the changes so far are:
>
> >> 1) Maven'ized the build with a comprehensive pom
> >> 2) added maven assembly to build a tomcat deployable distribution
> >> 3) added source code for the missing test code to make test code compile
> >> 4) added support for system property variable replacement in plugin and config files
> >> 5) added plugin to support using JMS to route messages to and from the gateway (JMS Outbound Support)
> >> 6) add support to ebms classloader to load all jar from a given directory and put jars in plugin/lib dir
> >> 7) added extension-point in ebms plugin for JMS support
> >> 8) added support for ebxml ping including support for displaying them in the UI
> >> 9) inbound message payload validation (only xml payloads and single schema) 10) Basic JMS inbound support, currently routes payload to a single queue
>
> >> Beyond that lies the Jentrata road map, with some enhancements underway and many planned.
>

> >> If you want details of changes at the code level you can take a look at the commit history on githubhttps://github.com/jentrata/jentrata-msh/commits/master

>
> >> My original commit really only contained maven build and project restructure the original code was pretty much left untouched.
>
> >> In terms of release dates I'm looking for a release around the end of August but we have the current build of Jentrata in production without issue.
>
> >> I would be keen to know what changes you've made to Hermes? I'm looking at building an open and healthy community and giving Hermes users a path forward which they haven't really had in the past certainly not one which they could get involved with.
>
> >> If you wanna chat sometime I'm often in the #jentrata IRC channel on freenode.
>
> >> cheers
>
> >> Aaron
>
> >>> Btw Aaron, at what time do you think the code-base will be "release-ready"?
>
> >>> Can I find any information on what adaptations you have made of the Hermes code-base on your webpages?
>
> >>> Regards,
> >>> Gustav
>
> >>> Hi Aaron,
>
> >>> The requirement is that the message should be delivered even if the listener-integration temporarily is down. So that would mean some sort of retry-functionality. However, I am not sure how it should handle several listeners where only the last one fails...
>
> >>> Regards,
> >>> Gustav
>
> >>> Hey Gustav,
>
> >>> Glad to hear you were able to build the code, maven build was the first thing I did.... I'm not a fan of ant builds :)
>
> >>> For inbound messages you mean right? We haven't yet put any handling of failed inbound messages.  As in inbound message payloads that failed to get sent via JMS. This only a problem if your JMS messaging system is down. What is your requirement for this feature?
>
> >>> We have worked around this current limitation by embedding ActiveMQ in the same tomcat instance as the gateway and using a ActiveMQ broker network to communicate with our backend ESB.
>
> >>> I  am planning to implement this feature. In fact the current inbound JMS handling isn't ideal and I want to rework it to make it a more general solution which would include making it reliable.
>

> >>> If you want you can raise a enhancement request on our issue trackerhttp://www.assembla.com/spaces/jentrata/tickets. You need to sign-up and then watch the project to be able to create tickets

> >>>> I would suggest checking outhttp://jentrata.orgbasically Jentrata is a fork of Hermes and it currently has JMS support (only ActiveMQ at this stage but I'm working on making configurable)

> >>>>>>> Yeah it's based on a newer releasehttp://community.cecid.hku.hk/download/beta/hermes2_src_20100331.zip

>
> >>>>>>> It is a beta but it's pretty stable have been using for the last few months without issue.
>
> >>>>>>> cheers
>
> >>>>>>> On 09/05/2011, at 8:49 PM, gustav80 wrote:
>
> >>>>>>>> Hi Aaron,
>
> >>>>>>>> I have a similar problem, but I cannot find the class
> >>>>>>>> EbmsEventListener in the H2o source code. Is this a new addition to
> >>>>>>>> the source?
>
> >>>>>>>> Regards,
> >>>>>>>> Gustav
>
> >>>>>>>>> Add an EbmsEventListener implementation to the ebms.module.event.xml
>
> >>>>>>>>> it might look something like
>
> >>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>>>>>>> <module id="eventModule" name="Corvus ebMSEventModule" version="1.0">
>
> >>>>>>>>>         <component id="messageListenerJMSClient" name="MessagelistenerJMS Client">
> >>>>>>>>>                 <class>hk.hku.cecid.ebms.spa.client.jms.MessageListenerJMSClient</class>

> >>>>>>>>>                 <parameter name="connectionUrl"    value="${jentrata.activemq.connectionFactoryUrl:vm://localhost?broker.persi stent=false}" />

[gustav80]

Ok, thanks alot!

Regards,
Gustav

On Jul 13, 2:16 pm, Aaron <aaronpwal...@gmail.com> wrote:
> Gustav,
>

> This commit shows most of the changeshttps://github.com/jentrata/jentrata-msh/commit/61d7ec9389dedeb048d36...
>
> This one for support in componentshttps://github.com/jentrata/jentrata-msh/commit/c1984ef09709091e58abe...

>
> But basically the commits in the period from the 2011-03-24 till the

> 2011-03-29 seehttps://github.com/jentrata/jentrata-msh/commits/master?page=3

> > >>>> I would suggest checking outhttp://jentrata.orgbasicallyJentrata is a fork of Hermes and it currently has JMS support (only ActiveMQ at this stage but I'm working on making configurable)

> ...
>
> read more »

[mike....@orchestrated.io]

Sorry, I know this thread is super old, but were there any updates regarding "requirement is that the message should be delivered even if the listener-integration temporarily is down".

We have a similar requirement, and as far as I can tell if the listener fails to execute, it will be logged but never retried or even have some sort of indication of failure in the stored record. 

[Aaron Walker]

Hi Mike,

Yeah right now there isn’t really any indication of failure. The simplistic view is that Jentrata runs an embedded activemq instance and if you only have a single Jentrata instance (no cluster) you can rely on that instance which is running as long as Jentrata is. Typically this instance can be easily bridged with another activemq via some simple camel routes.

Here’s a basic example which bridges jentrata with jboss-amq https://gist.github.com/aaronwalker/59648cc5302695e91b149ccc52977b4c

Now that said I have always planned to improve the Jentrata JMS integration options and make it much more of a first class citizen which I have kinda done on the AS4 jentrata version.

That said if you want to raise a issue on github with some details of what you’d like to see that would be appreciated and a pull request will even more so :)

cheers

Aaron Walker

--
You received this message because you are subscribed to the Google Groups "jentrata" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jentrata+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.