Add messagid as option for Jentrata client and server

[cavycorp]

In some cases we need to be able to control the messageid as being used within the ebXML message as being sent by Jentrata. For this we made a small modification in the webservice interface of Jentrata to allow for clients to provide a messageid. We think this change can be useful for other Jentrata users.

[aaronwalker]

@cavycorp it is possible to set the ebXML message Id when using the jentrata integration plugin See https://github.com/jentrata/jentrata-msh/blob/master/Plugins/CorvusEbMS/src/main/java/hk/hku/cecid/ebms/spa/handler/jms/EbmsMessageHandler.java#L59

Heres an example of an integration https://github.com/jentrata/jentrata-msh/blob/master/Dist/src/main/deploy/example-ebms.xml.example you can basically rename this in the deploy directory and jentrata can pick a payload file from a folder and deliver it. It is possible to use pretty much anything supported by apache camel. For both inbound and outbound.

Ive had in the back of my mind to use this to implement a REST Api using built on top of the jentrata integration plugin.

But happy to accept any PR for the SOAP api as long as it backwardly compatible.

[cavycorp]

@aaronwalker I will look into it.

[cavycorp]

@aaronwalker,

We currently use the SOAP WS for our clients.
The change I propose will change the WSDL (EbmsMessageSenderService.wsdl) however the part "messageId" will be added as an optional field. The underlaying server code (EbmsMessageSenderService.java) will check if the messageId is used, obtained a value, if not the original code which generates a messageId will be called.
With these changes the SOAP WS of Jentrata will be backwards compatible. I will provide the changes probably tomorrow.

[cavycorp]

@aaronwalker, a question concerning the addition of messageId as an input parameter. Should I also add code to verify the format of the messageId, to see if it is compatible to the standard? As far as I can see there is no code to do this verification within Jentrata, for example the refToMessageId isn't checked either.

The Jentrata implementation doesn't care about the format of both messageIds, any string is accepted but other ebMS2 implementations might fail when it receives a message with an incorrectly formatted messageId.

Let me know what you think.

[aaronwalker]

@cavycorp yeah I am happy for you to add validation but maybe it should be possible to disable it and have it disable by default to ensure existing compatibility

[aaronwalker]

@cavycorp maybe we have a strict compliance setting/mode for these types checks... thoughts?

[cavycorp]

@aaronwalker yeah it might be better to leave the validation out for existing compatibility and think about, as you say, a compliance setting/mode.

I will add it without validation, the compliance mode is then something for a separate issue.

[cavycorp]

@aaronwalker, how about this change?