Comments (4)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 Katherine Sanders commented Permalink

I'm curious if you considered using WebSphere Cast Iron Cloud Integration to perform the functionality of the aggregation framework to accelerate development? And if so, why did you choose to use custom coding instead? It also has a built in adapter for Siebel that might have allowed you to avoid the use of the SWSE interface.

2 Thomas Hesse commented Permalink

Very good question. Thanks for that! You are absolutely right. WebSphere Cast Iron Cloud Integration might be a very good match for projects like this. For this demo, the team has re-used a custom-coded SWSE aggregation framework which had been developed earlier for other purposes and which also seemed well-suited for this Worklight demo project. Also please note that at the time when the team started the development, the Worklight Cast Iron adapter was not available. Today, we would definitely consider using Cast Iron and the Worklight Cast Iron adapter. I am not so sure about the Cast Iron Siebel adapter, because it is accessing the Siebel system on a BO/BC or IO or BS level. But in many Siebel projects, a lot of business logic is developed on a view or applet level, and SWSE allows you to directly re-use this business logic.

3 Katherine Sanders commented Permalink

OK so it sounds like Cast Iron may not be suitable if you need access ot the view and applet level, will keep this in mind if I get a Siebel project in future, thanks for the extra information!

4 Thomas Hesse commented Permalink

Well, actually it is the Cast Iron Siebel adapter which might not be suitable in those cases (because it is operating on the Siebel BO/BC or IO or BS level), but the WebSphere Cast Iron Cloud Integration platform might still be helpful for aggregating the calls to the SWSE Web Service layer (which is operating on the Siebel view and applet level).