Set multiple in-memory keystores to handle different pModes

[binaradarsha]

Hi,
We are going to handle multiple pModes in our as4 server project. i.e. BPC and Peppol. Looks we need two AS4CryptoFactoryInMemoryKeyStore objects due to it accepts only one key alias-password pair.

In our custom AS4Servlet we have AS4XServletHandler.setCryptoFactorySupplier(() -> cf).
I am thinking if this Supplier.get() function would have a pMode parameter that injected for each document received like
AS4XServletHandler.setCryptoFactorySupplier((pMode) -> if(pMode == "BPC") cfBPC else cfPeppol).

Is my requirement is still achievable in a different way that I couldn't figured out yet, or needs to be implemented in phase4?

[phax]

So for sending it is pretty straighforward - you just place the right IAS4CryptoFactory in the right place.
However, when receiving it becomes a bit more tricky.

The "problem" I can see here is, that neither Peppol nor BPC use "PMode" in the intended way, due to the dynamic participant handling, Therefore I assume problem is similiar to #117 and the proposed solution in #121.

So if you implement you own IAS4CryptoFactory that also implements the interface IAS4PModeAwareCryptoFactory you can make the right choices, based on the context PMode.

However, while thinking about this - you need to make sure your solution is thread-safe, so that the conext PMode is e.g. stored in a ThreadLocal or so

[phax]

Well okay, the PModeManagerInMemory is the default instance that is created via the AS4ManagerFactoryInMemory which is instantiated via MetaAS4Manager.
Honestly it is hard to make definitive assumptions about your setup, without looking at the code ;-) The dynamic PMode IDs are created via the default implementation of IPModeIDProvider.
The default BPC IPModeProvider implementation stems from the AS4BPCProfileRegistarSPI, assuming that BPC also uses the "dynamic PMode concept" as OpenPeppol does. Why do you want a single PMode with a single combination of sender and receiver for BPC by the way? Are you including the phase4-profile-bpc artifact in your code?

In general I would recommend to setup separate instances for separate networks. The detailed configuration might become quite messy, as can be seen here....

[binaradarsha]

I will look into with PModeProvider and related stuff you have mentioned. Yes, we are using phase4-profile-bpc artifact in our project.
Our organization needs to handle all AS4 profiles by a single service. We have to keep up with organizational decisions and so need to solve this problem somehow.

[phax]

Okay, eventually you can provide multiple "endpoints" (aka Servlets) to deal with Peppol AS4 messages on "/as4peppol" and receive BPC stuff at "/as4bpc"? That way you can easily configure 2 different receiving handlers with different setups etc.

[binaradarsha]

Yeah, that is also a good alternative. Once initially I thought to have separate Servlets, but then considered having two urls would be problematic. But looks we just need to register "/as4bpc" in BPC network and "/as4peppol" in Peppol network. I will discuss with our colleagues who have more understanding regarding this stuff.
Thank you!

[binaradarsha]

Hi, we moved forward with a single url "/as4" using the workaround below in our AS4Servlet.

final AS4XServletHandler servletHandler = new AS4XServletHandler();

servletHandler.setPModeResolver((sPModeID, sService, sAction, sInitiatorID, sResponderID, sAgreementRef, sAddress) -> {
    if (sPModeID.equals("BPC")) {
        return BPCPMode.createBPCPMode(sInitiatorID, sResponderID, sAddress, (i, j) -> sPModeID, false);
    } else if (sPModeID.equals("PEPPOL")) {
        return PeppolPMode.createPeppolPMode(sInitiatorID, sResponderID, sAddress, (i, j) -> sPModeID, false);
    }
    return null;
});

sPModeID is one we set in our Phase4BPCSender/Phase4PeppolSender.pmodeID() method in client side.

In our IAS4PModeAwareCryptoFactory implementation we used a ThreadLocal variable to store the IPMode object as you have suggested. When a thread pool is used, for handling a message a thread is picked from the pool, it will have its own copy of IPMode object, finally when finished message handling it will be released to the pool with keeping the IPMode object. Then if that same thread is picked again for another message handling, it's IPMode object is overridden and we don't need to manually remove it beforehand the thread is released to the pool.
Is this correct or do you recommend to manually remove the IPMode object?