To Dual Stack or Not Dual Stack?

Since the release of the AEX, I have been asked repeatedly by colleagues, acquaintances, and customers whether or not they should jump feet first into the new single stack offerings of SAP NetWeaver PI. Having worked with PI since the XI 3.0 days, I find myself struggling to let go of that dual-stack security blanket. In time, this decision will likely be made easier by SAP ripping the ABAP band-aid off of PI altogether. In the meantime though, here is a collection of thoughts I have on whether or not to migrate to a single stack architecture. These reflections are in no way meant to be taken as gospel, just the assorted musings of a developer and his experience working with the tool.

Limitations/Problems with the Current Java-Only Solution Architecture

On the surface, a single stack solution based on Java technology makes so much sense. After all, a dual stack solution consumes many hardware resources, is more complex to maintain/troubleshoot, message processing lags due to stack hopping, and so on. Plus, ABAP is not exactly great at dealing with Internet protocols, XML parsing, etc. The problem (as I see it) has always been that SAP has never had one single AS stack that was robust enough to provide everything a modern Enterprise Service Bus (ESB) requires. In particular, I see the following limitations on the Java side of the house:

1. There’s no good way to say this, so I’m just going to come out and say it: the AS Java is not as robust and reliable as the AS ABAP. I love Java as a language and as a platform for building enterprise applications, but it’s really hard to beat the AS ABAP when it comes to having a rock solid platform to deploy applications on. It simply doesn’t die, no matter how many bad SELECT * statements lazy ABAPers throw at it. And while the AS Java continues to mature and become more reliable, I sleep better at night knowing my mission-critical transactions are flowing through the Integration Engine. It may bend under a heavy strain, but it rarely breaks. With the AS Java, I always feel like I’m a java.lang.OutOfMemoryError exception away from lying crippled on the side of the road.
2. Though it is possible to tune JVMs and build large clusters of AS Java server nodes, the reality is that most PI projects I have been a part of have struggled with AS Java performance. Of particular concern are large spikes in message volumes and/or large messages coming through the pipe.
3. The Java-based runtime environments are not very transparent and difficult to trace. Though the monitoring tools in PI 7.3x have gone a long way towards leveling the playing field, I still think they trail behind what has been established over in the IE. There, I can suspend qRFC queues, set breakpoints within pipeline services and get to the bottom of the most complex of problems with ease. Conversely, if a message gets hung in the AEX, it can be difficult to get to the source of the problem with the current set of tools available.
4. To me, one of the biggest things that has always set PI apart from other EAI tools is its robust ABAP-based IDoc adapter. While all of the other competing vendors have struggled to keep JCo-based IDoc adapters up and running, PI has always provided excellent support for IDocs. Not to mention all of the extra bells and whistles such as qRFC support, packaging, and so on. JCo, in my opinion, is a fairly leaky vessel and not one I want to trust for delivering important messages to/from ECC systems.
5. The Java logistics infrastructure is a still kind of a mess. These days, integration content is scattered across the ESR (accessed either directly or indirectly via the NWDS) and the NWDI (particularly for BPM content). Though CTS+ is simplifying the way that these disparate content types are promoted across the landscape, this is a lot to consume for novice Java-based integration developers new to SAP.
6. Lastly, it is difficult to find good PI admins who really know their way around the AS Java. Over the years, I’ve often had to wear the Basis hat on PI projects, knowing that I was on my own if there was a Java issue that cropped up. Here, if worst came to worst, I usually had the option of refactoring my integration scenario to utilize ABAP components so that I could get the support I needed. Once the dual-stack plug is pulled, it’s sink or swim.

The Verdict?

For now, it is this developer’s humble opinion that customers running mission critical integration scenarios should stick with the dual-stack architecture as long as they can with a few caveats:

• Developers should make a conscientious effort to utilize AEX-based features as often as they can. For example, if a scenario does not require features of the AS ABAP, it should be packaged up in an integrated configuration and deployed on the AEX.
• PI Developers and Basis admins alike should brace themselves for a future which doesn’t include the AS ABAP. They should explore the features of the AEX, Process Orchestration, and so on.
• Any new solutions requiring Integration Processes should be considered long and hard as they are not compatible with the Java-based BPM functionality. Suffice it to say if BPM is a big part of your PI footprint, then some serious thought should be given towards the future of Process Orchestration.
• Integration architects should continue to nudge developers towards the use of SOA-based designs utilizing enterprise services where they make sense as opposed to older legacy technologies such as IDocs and RFCs. Not only is this a best practice, but it also reduces reliance on shaky JCo-based technologies.
• Middleware teams should take begin putting together maintenance/monitoring plans which utilize the new SolMan/NWA/PI Java-based toolsets. This will make it easier to migrate over to the single stack solutions down the road.

For now, the dual stack solution provides developers with the best tool coverage available. So, unless your server admins are desperate to re-coup server resources, I see no reason why you would want to give that up as a developer – for now. Hopefully a couple of years from now, this will be a slam dunk case and we’ll all laugh at why SAP ever had a dual stack architecture to begin with.