SCW Strategy - CPU/Memory Intense/problems?

Question

I am trying to see the impact on XI Server with 3 SWC strategy.
Just brief on 3 SWC Strategy  - Source and Destination of interfaces as separate SWC and mapping is 3rd sWC for each interfaces. However to get this 3 SWC working, we need to create dependencies in SLD .
AS XI creates Java Objects on backend after you config in GUI, and having references it may impact on GC collection and as well on CPU.  So if this strategy is applied for larger projects, may cause GC to keep these SWC Objects and in turn relevant XI objects (Source, message type, mappings etc ) tied to each SWC in memory and not to flush thru GC cycles. I think this also impact on CPU Processing. I also experienced problems with migrating feature versions to production path as it requires migrating these Interface objects in correct order to load java objects properly and refresh references, and also requires bounce server to refresh objects with pointing to recent migrated Interface (java) objects. It looks complex, but trying to present on my thoughts on backend XI JVM processing. I have not seen many customers implemented this new SWC strategy also.
I thought of posting this to SDN to seek your thoughts!!

Answer 1

Hi,
I admit that the usage of multiple SCW creates confusion for the new person. But Considering the Reusability & scope of several Business processes, these kind of models are necessary in complex/ large scale industries where the mutiple applications/systems integrate together. 
Have you guyes referred the SCV strategies discussed here,
/people/thorsten.nordholmsbirk/blog/2006/07/25/structuring-integration-repository-content--part-1-software-component-versions &
/people/thorsten.nordholmsbirk/blog/2008/12/10/structuring-integration-repository-content--part-2-software-component-versions-revisited
I think the concept of Base & Canonical SCV mentioned in 2nd blog would be good approach....but of course it depends upon the scop of interface and Business Process.
Ravi had mentioned very good point about
AS XI creates Java Objects on backend after you config in GUI, and having references it may impact on GC collection and as well on CPU. So if this strategy is applied for larger projects, may cause GC to keep these SWC Objects and in turn relevant XI objects (Source, message type, mappings etc ) tied to each SWC in memory and not to flush thru GC cycles. I think this also impact on CPU Processing. I
--> Certainly I doubt if there would be major impact with referecen to GC. The model/strategy you will be setting up that's permanent model....so contineous changes are NOT excpected in it....then that will not be the correct strategy.
THe Garbage Collection will increase, if the dependecencies where changed contneously and that would affect the memory/resource utilization by server.
I think the Base/Canonical way of organizing the SCW, may help to clarify the picture and alo it won't affect much as the dependecies will not be affetced between SCWs.
THanks
Swarup