SCW Strategy - CPU/Memory Intense/problems?

[Former Member]

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!!

[Former Member]

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

[former_member200962]

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 .

If I am a support person handling such a landscape I would surely get confused as to which SWC to refer to in case of an issue!

Personally i feel it is not a good idea to implement such a SWC strategy..... from the functional point of view if you want to explain XI objects of your project to a new comer/ knowledge transfer to the client.....this design approach will cause an increase in the readability of the development...my opinion

Let us wait for comments from experts.

I have not seen many customers implemented this new SWC strategy also

Is there any documentation available for this?

Regards,

Abhishek.

[Former Member]

I agree that SWC can't be just one per project, we all agree and personally recommended to categorize SWC per Functional area, and interfaces are categorized into

nameespaces, and if it is really sharad components, you create SWC for shared components really shared across interfaces, can be more than one depends on category) and define SWC dependency so that relevant sWC can refer to shared SWC.With this approach, GC cleans as soon interface is done, and keeps unavoidable (really necessary) shared SWC in memory. I still recommend to use shared (referencable) SWC as needed, but not just by Source and Target Systems

Here I am trying to make point on how it would impact on XI JVM and taking the 3 SWC approach for larger projects, say 500 interfaces, how it would impact on XI JVM, GC, inturn resources. As longs as you made any sWC as reference (all source and destination SWC, and objects tied to each SWC within source and destination), once they are executed for individual 3rd SWC first time, it stays in memory and never get cleaned by GC as it is intend to reference others, When we modify any of these shared (Source, Destination systems) SWC, it requires bounce Java Stack to 100% ensure it is loaded (refreshed) into XI memory so that other SWC is refering to latest version.

Let us say Large company has 3 projects, each one has 200-300 interfaces, and 20-30 systems to integrate per project needs, 3 SWC, keeps more objects in memory all the time,, where as categorized SWC, and further categorized interfaces with namespace, will only keep objects into memory as needed, there are other maintenance related

issues, I could personally experienced with shared components from previous customers, but this thread i am limiting to major points.

I am thinking as we use this SWC in larger projects, we soon see these kind of challenges/problems. Since it is one of the recent recommendations on SWC, trying to just understand and get thoughts from community/forum so that customers can get some feedback on these approach before implement.

[Former Member]

HI Ravi,

As 3 SWC strategy involves more maintanace most of the developers won't prefer this.

As you pointed out it requires more system resources then the normal approach it is not feasible.