jentrata / jentrata-msh

Jentrata - Message Handler Service
jentrara.org
Other
19 stars 57 forks source link

Add messagid as option for Jentrata client and server #63

Open cavycorp opened 5 years ago

cavycorp commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@aaronwalker I will look into it.

cavycorp commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

cavycorp commented 5 years ago

@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 commented 5 years ago

@aaronwalker, how about this change?