Hi David,
if you would like to thank me, please mark the reply as the "Correct Answer" if it answered your question, or mark it at least as a helpful one - regardless if you like its ontent or not (there's a separate button for liking posts).
You may of course have the opinion that the separation of concerns principle is bad design, but I disagree. There are also developers who do not like the model-view-controller architectural pattern, or object oriented programming as a whole. But I think, once one has understood this, one will also see the advantages.
Yes, if you are sole programmer that has to take care about all alone anyway, the separation of concerns indeed requires a little bit more effort first, but one will see the benefits if some maintenance is needed in the future or something fundamental needs to be changed (e.g. the underlying database for storing the user logon data needs to be exchanged or simply it should be replaced by an LDAP service). With the JCo3 design you just have to adapt your infrastructure implementation project and not all your numerous deployed different applications. There are several more advantages, but as you desired, this should not be an architectural discussion, you only asked how to work with the DestinationDataProvider.
I tried to give you the answer in my last reply. And by the way, there IS a default implementation of the DestinationDataProvider that works with local property files, but this is only meant to be used for quick development purposes and not for productive use. Once there is a registration of some own DestinationDataProvider instance this one is used globally in the whole process (the application server) and also cannot be retrieved from the JCo environment by foreign applications. Remember: the idea with the separation of concerns is that the business application shall not depend on any specific infrastructure implementation and it shall not contain the technical configuration data which ABAP application server to connect to (this is the task of an administrator). The business application only needs to know the logical destination name and shall focus on the business logic instead (i.e. which remote function module shall be called with what parameter data?).
Anyway, there is no software concept that cannot be broken if one really wants to. This is how the quick and dirty solution would look like:
Develop a DestinationDataProvider implementation class that offers two additional methods:
1. public static <OwnDestinationDataProviderClass> singleton() : for getting your single object instance of this class
2. public void setDestinationProperties(java.lang.String destinationName, java.util.Properties props) : for storing arbitrary JCo properties mapped to a destination name
Then all applications need to have have a reference to the DestinationDataProvider application and so can get the global <OwnDestinationDataProviderClass> single instance (thus introducing the dependency to the infrastructure again) and can fill in their logon parameters to the internal data sink (thus mixing the administrative data [hard coded logon parameters] into the business application program again).
But just to mention one disadvantage of such an implementation: If you have deployed 10 applications which work with the same hard coded logon parameters and some connection data to the AS ABAP back-end changes (e.g. like a password or the hostname), then a developer is needed for modifying, recompiling and redeploying all your 10 different applications one by one. In contrast to this, how easy would it be for administrator to change the configuration data centrally once for all applications - even if the various applications stem from different developers and/or vendors?
And to your final question:
No, JCo3 is designed as a process global framework with reusing and minimizing the needed resources (like reusing connections and repository RFC meta data). You should not try to deploy JCo with each of your own applications. You will also probably fail if doing so, as the JCo native library cannot be loaded multiple times in one process.
Best regards,
Stefan