Composition Environment: Towards A Greater Convergence?

In the past few months, I’ve had many fascinating and educative discussions with people from the Composition Environment ecosystem: developers, architects, consultants, and solution managers both at SAP and at customers, and partners. (My employer is an Independent Software Vendor that develops application on top of NetWeaver and we participate in the ramp-up of CE 7.2)
In the course of one such discussion, I had one of these insights that everybody gets occasionally – a bit of an idea of a bigger picture, or a possible trend in the NetWeaver world, that I would like to discuss with you.

Pluggable persistence providers

First, some details. (I’ll assume that you have basic familiarity with SAP NetWeaver Composition Environment and Java Enterprise programming.) At first, SAP conceived their JPA 1.0 implementation SAP JPA as a “hard-wired” component of the server which may not be replaced with alternative implementations. A bit later, the Java EE 5 (EJB 3.0) specification changed so that persistence providers became pluggable, meaning you can use any standard-compliant persistence provider in your project.

This means that you are free to use, say, Hibernate or EclipseLink instead of SAP JPA in your project. In fact, SAP supports this through SCN with how-to articles and guidance provided in the forums.

The immediate impact

What is the immediate impact? First of all, you win the freedom to use a number of excellent, robust, well-documented and widely adopted Open Source persistence providers. Looking at the forums, you can tell that this option is in high demand by customers and partners.

Impact on the tool chain

Secondly, there’s an impact on the tool chain in the Composition Environment:

• You cannot use EclipseLink with the System Datasource, so your application will use a database (scheme and connection) outside the default database used with SAP JPA and OpenSQL.
• While the SAP forces you to use the lowest possible isolation level in the system database, they actually recommend using a higher isolation level when using an external datasource.
• The system datasource with its lowest isolation level forces you – in some scenarios – to use pessimistic locks managed by the Enqueue Server. When using an external datasource with a higher isolation level, you no longer require the pessimistic lock service to provide the isolation and can use optimistic locks without fear of transactional inconsistences.
• You cannot use the Java Dictionary to deploy database tables and contents. It’s unclear whether you can use Java Dictionary DCs at all with EJB DCs that use a non-SAP persistence provider.
• No OpenSQL outside the system datasource – no using the OpenSQL monitor in the NetWeaver Administrator, no OpenSQL table buffering, no guaranteed support for every database management system listed in SAP’s Product Availability Matrix (PAM).
• CAF entities cannot be used in the same transaction because they always use SAP JPA, the system datasource, OpenSQL, and Java Dictionary.
• Obviously, SAP will provide support and bugfixes for SAP JPA but not Hibernate or EclipseLink. You can rely on the respective communities for support or enlist a company that provides professional support for your Open Source components.

The consequences

• Does that mean the tool chain is broken? – Yes, in parts it is.
• Does that mean that SAP recommends not to follow the ABAP-inspired database programming paradigm? – Yes, it does. (They’re not saying this very loud but the message still gets around.)
• Does it break SAP’s heart if you use standard Java EE programming paradigms instead of established SAP-specific models? – Not at all, they’re completely cool about that. In fact, they recommend that you do
• Will you, by doing so, bar the way to the adoption of future developments by SAP? – Not according to them.

This is quite different from SAP’s previously held stance (and reality) that failing to follow SAP’s proprietary programming models and use their tools would invariably lead to a future penalty because your missing compliance with SAP standards would bar the way to using (i.e. reaping the benefits of) future SAP tools and integrations.

(Disclaimer: When I write “SAP recommends this or that,” I do not  refer to an official positioning or statement but to the word that gets  around inofficially but consistently when you chat with people from SAP  at TechEd, on-site, or in Walldorf.)

Increased standard compliance and reduced internal cohesion

And that’s when I finally understood what is currently happening in the SAP world. The following illustrations attempt to show what I mean.

In the first image you see the classical positioning of SAP-tools: tightly coupled, with a high degree of internal cohesion and an unbroken tool chain. One of SAP’s core strenghts is that the integration of its components is much tighter than what you see in the Open Source cluster of more loosely integrated components.

Fig. 1: SAP and Open Source in different corners

Fig. 2: SAP approaching Open Source while losing internal cohesion

The second illustration shows what is happening right now. SAP is moving towards the world of Open Source and open standards. Some components make the transision faster than others, resulting in some drifting apart. While a lot of proprietary SAP stuff is still on board (and will be supported for a long time), looser integration with non-SAP components is becoming more common. This means that a “broken tool chain” (meaning a tool integration that is perhaps less tight than traditionally in SAP) becomes a more normal sight. It’s the cost of opening up for non-SAP components.

Convergence and divergence

Inside the SAP tool suite, we have experienced a very strong trend towards convergence of the tools in the past few years. ABAP and Java used to reside together on dual-stack systems with shared memory areas, their Web Dynpro variants looked very similar and could be seamlessly integrated through the Portal and Guided Procedures; both application servers used the same database programming paradigm, database isolation level, locking concept, and enqueue server, and the interoperability and integrability of the systems would get better every day.

While much of this is still true, we can observe ABAP and Java drifting slowly apart: dual-stack is obsolete, the database programming models differ, the Web Dynpro variants are diverging faster and faster, and the ABAP-based Business Suite applications are reducing their dependency on the Enterprise Portal (see CRM WebClient UI’s stand-alone capability and own role concept).

Consider, also, that CE’s BPM will be able to embed Web Dynpro ABAP user interfaces only in its third release (at least – depending on how many EHPs you count), and you can see that the tight and seamless integration of every component of the NetWeaver ABAP and Java stack are less of a priority today than they used to be a few years ago.

On the other hand, a less tight coupling with some functional redundancies between the two allows for a more healthy, loose coupling of the technologies where each system has more freedom to finds its best place in the SAP universe.

So while we are experiencing some rather unheard-of – and possibly temporary – divergence in the SAP tool world, we can observe a convergence insofar as SAP is approaching, and adopting (and possibly becoming a part of) the world of Open Source and open standards. And this greater convergence may ultimately turn out to be far more significant. But it’s too soon to tell. In future installments, I will discuss some aspects of this apparent shift in the product vision.