This content has been marked as final. Show 2 replies
You don't have too many options here since 2 independent SOA installations (i.e. 2 weblogic domains each having exactly one SOA cluster) cannot share the same MDS. The MDS is the source of truth to identify the list of deployed composites, hence if they would share the same MDS they would also run the same composites. Furthermore, such a topology is not supported either. Also note that you also cannot have more than one SOA cluster in the same Weblogic domain.
So in other words, if you need to have different lists of composites on separate runtime environments, you also need 2 weblogic domains running a SOA cluster each as well as 2 unrelated MDS schemas.
The challenge here is as you correctly indicate the communication between the 2 SOA environments. Since there is no co-location between such composites, the interaction would happen via SOAP over http with all implied facts such as loss of global transactions and performance degradation due to marshalling/unmarshallig of payloads.
Because of this we recommend to co-locate all composites that are part of a particular integration flow on the same SOA instance. Note that this might imply to have some artifacts deployed twice on both SOA installations.
We have worked on designing deployment designs for similar use cases in the past, so feel free to reach out to me offline (email address is in my profile) if you want to discuss this further to evaluate your use case and we will try to help figure out the best deployment topology for your case.
SOA has a concept of partitions where composites can appear in seperate lists in enterprise manager. This is useful for seperating the lists out. You can also retire and activate a whole partition in one go.
The problem is that AIA deployment plans don't support partitions. I did see a post on here which explained a few simple changes which would make AIA support putting composites into seperate partitions.