SAP NetWeaver
An Overview of the New SAP Concept
The ABAP-speaking developer community in Walldorf is increasingly speaking Java. This process of evolution began when SAP acquired InQMy along with its ready-to-market J2EE technology, and Hasso Plattner (the co-chairman of SAP) announced that ABAP and Java would rank equally in application development at SAP.
Subsequently, many SAP customers decided to focus their Java development on the SAP Web Application Server (SAP Web AS). With SAP Web AS 6.20, the technology passed its critical test: a considerable portion of SAP applications and a large number of customer-developed applications were running in the Java environment of the application server. With the latest version, SAP Web AS 6.40, scheduled to hit the market in a few weeks from now, this series of articles is intended to provide an overview of: Where is SAP with its Java offerings now? What is new and what will stay as is? What does the future hold?
In the first in a series of articles we'll focus on SAP NetWeaver and provide an overview of the new SAP concept.
In the Web AS architecture both the Java and ABAP systems can exist concurrently (provided both are installed, of course). It is also possible to use only one of the runtime systems at a time -- the Java runtime would behave like an ordinary J2EE server when the ABAP page is missing, while also harmonizing with the characteristics of its counterpart, ABAP.
The Web AS architecture emphasizes the independence of Java runtime in a number of ways. For instance, the applications on the Java side run in a separate database scheme. On another note, the data managed by ABAP programs is usually stored in the same database, albeit in a different scheme. So a Java program can access 'ABAP data' only in an ABAP program by calling the APIs - though it is a slight detour, this is the most reliable solution considering the different transaction terms in J2EE and ABAP.
Figure 1: One Server - Two Runtime Systems
The Java side has a separate data dictionary that manages data definitions for the Java programs, and, as and when necessary (to exchange information on the data structure that can be found in APIs, for instance) it communicates with the ABAP side. On a different note, most other areas aim to harmonize the Java and ABAP operations of Web AS, especially in the case of clustering and monitoring of a running system. Cluster Architecture
When the number of users increases and one server is no longer sufficient, questions arise on how the load is distributed on multiple instances and how the server instances communicate with each other. In Web AS 6.20, clustering on the Java side works by peer-to-peer communication of instances with equal rights. The advantage of this approach is that there is no specific central instance whose failure could paralyze the system. The disadvantage is that communication requirements increase, more than proportionally, when the cluster size increases.
Web AS 6.40 differs from this scenario. In the latest version, the Java side uses the same clustering that has always been used for the ABAP side. In addition to the pure application servers, there are two central servers for special tasks:
- The message server that distributes the incoming requests to the application servers. Because the message server is the only one that knows all application servers, all communication between the application servers runs through this server.
- The enqueue server through which the application programs can request locks for the application objects they intend to process.
In terms of administration and control, the Java side of Web AS offers a range of tools for administration and monitoring that provide a complete image of the system even during a stand-alone operation:
- All Java-based applications can use special logging
- Tracing functions, which can be added in steps, provide comprehensive statistical data about the performance of important system components
- The Visual Administrator, shows important information about the system status while also allowing to change all relevant parameters to fine-tune the response behavior
Figure 2: Cluster Architecture
The main focus, however, is on integrating monitoring functions with large system landscapes, including "homogeneous" networks of SAP systems or mixed landscapes. SAP Web AS Java can send its data to the SAP proprietary monitoring product, Computer Center Management System (CCMS), and also to any other receiver (based on the JMX standard, of course). Security
As a certified J2EE-1.3 server, SAP Web AS supports all security standards required under the J2EE specification, like JCE, SSL, and X.509 authentication JAAS. It also contains extensions for the following tasks:
- Integration of external user databases
- Usage of individual program modules for authentication
- HTTPS client library
- "Secure store and forward" for confidential data Key store services (encoding documents with digital signatures, that is)
In general, security also requires a bridge to the ABAP side to create consistent user management for the entire landscape, including the SAP systems. The User Management Engine (UME), new in Web AS 6.40, provides a consistent API for all Java-based SAP NetWeaver technology components (like SAP Web AS, SAP Enterprise Portal, and SAP Exchange Infrastructure) for user data access - the user database can also be situated externally, for example, in an LDAP directory.
The SAP authorization concept has a multi-level structure that allows complex authorization scenarios, like:
- Permissions that allow specific operations on specific quantities of objects in the real world
- Actions that are combinations of permissions that, together, allow a specific business action to be carried out by the user
- Roles that are groups of actions that users must be able to execute in order to be authorized for a specific company position
Even in respect to application architecture, the double role of SAP Web AS is significant. Not only does it fulfill the usual Java standards, but it also consistently adds elements that have proven themselves in the SAP application architecture.
Figure 3: Database Access Layer
In some areas, J2EE 1.3-certified Web AS 6.40 exceeds the scope required in the specification - for instance, the anticipation of the J2EE standard is visible both in the implementation of the Java Connector Architecture (JCA) 1.5 and the support of the WS-I standard in the important domain of Web Services. Complete J2EE 1.4 support, however, is not foreseen until the next version of SAP Web AS. Platform-Independent Database Access
As is already the case on the ABAP side, SAP Web AS provides application programs with a common database access layer in the Java environment as well. This layer not only offers mechanisms that increase performance, such as table buffer or statement pooling, but also makes database access portable across various databases like Oracle, IBM DB2, Microsoft SQL Server, and MaxDB. A specific SQL subset (Open SQL) hides the characteristics of the various databases so that applications can run on different databases without any changes.
All programming models that SAP offers for database access are based on this common layer. The programmer can choose whether she wants to address the database per JDBC - as designated in J2EE 1.3 - or encode access in accordance with the SQLJ industry standard, a specification in which nearly all major database manufacturers participate. SQLJ allows more static compile-time checks and is therefore preferred by SAP for proprietary development.
In addition to table-oriented methods, object-oriented models are also offered for database access. SAP generally focuses on the Java Data Objects (JDO) standard in this field. However, database access can also be organized via Enterprise JavaBeans (EJB) with the choice between Bean-Managed Persistence (BMP) and Container-Managed Persistence (CMP). Regardless of the application developer's choice (as long as she is not deliberately programming against the proprietary driver of the respective data base manufacturer) all accesses pass through the common layer, which means that they are portable and that they use common pools and caches. Connectivity
In addition to the central message server for communication in the cluster, there is also an implementation of the JMS standard (Version 1.02b) for connections between applications, and servers too. This implementation was built directly into SAP Web AS. Thus, messaging under JMS does not require a separate server instance.
J2EE-Standards JCA/JRA and RMI can also be used (via IIOP) to expose specific services for external Java applications. A CORBA implementation for data exchange with non-Java applications is also available.
In general, SAP regards Web Services as the ruling standard for the publication and use of services within large organizations as well as beyond enterprise boundaries. Due to the particular significance of Web Services, we'll deal with this topic in a forthcoming article in this series. For now, all we need to know is that SAP Web AS supports all the common protocols in this field, like UDDI, WSDL, and SOAP. Moreover, the tools in SAP NetWeaver Developer Studio make it easy for the developer to make her results available as Web Services or to use the Web Services of other providers in her project.
In a short term, Web Services are expected to replace even the popular SAP JCo (Java Connector) interface, which is (currently) the connection of choice from Java to ABAP-based applications. SAP JCo is also responsible for connections within the same SAP Web AS and often necessitates the separation of the data world for Java and ABAP programs (see above). User Interfaces with Web Dynpro
Another field where SAP is making its own way is in User Interface (UI) design. SAP has created a programming model - Web Dynpro - that provides new possibilities for GUI Development. Web Dynpro is based on a meta-model for abstract description of user interfaces using the established separation of model, view and controller (MVC). Using special, graphically-oriented tools in SAP NetWeaver Developer Studio, the developer can create a description of her application in accordance with this metamodel to generate code.
Figure 4: SAP NetWeaver Developer Studio
The generated code relies on Servlet, so that the business logic runs completely on SAP Web AS. Nevertheless, the runtime system - using the completed application - also includes client software: the client-side framework (CSF), implemented in JavaScript, receives page descriptions and raw data from the server and generates the HTML shown in the Internet browser.
The three significant benefits that result from this process are as follows:
- Nothing is installed on the front end (no applets, no ActiveX)
- CSF ensures a degree of interaction that is generally missing in HTML-based applications
- The programmer comes into contact with neither HTML nor JavaScript but only with Java
SAP Web AS cannot be comprehensively described without discussing the associated development environment - SAP NetWeaver Developer Studio. In the SAP strategy, the development environment and the server form one single unit - they have been optimized to one another, each helping the other make best use of its strengths.
Developer Studio is a harmonized group of plug-ins for the Open Source framework, Eclipse. Special tools have been created for the components of SAP application architecture and (as is customary in Eclipse) combined into Perspectives. Perspectives allow tools to be arranged on the screen in such a way that they optimally interact in a specific field. The studio, therefore, has specific Perspectives to create UML models, EJBs, Web Services, Web Dynpros, and so on. Since the studio wants to cover the entire application development process, there are also tools for the data dictionary, data access layer, and UML modeling, as well as for the debugging and monitoring of servers.
Figure 5: Developer Studio and NWDI
For deployment, the SAP NetWeaver Developer Studio development tool creates special archives, called Software Delivery Archives (SDAs), and transfers them to an integrated service in SAP Web AS, called Software Delivery Manager (SDM). The SDM takes care of the rest: The application can be started immediately.
In Developer Studio the emphasis is generally on graphic-oriented tools, where modeling has priority over coding. This is particularly true for user interfaces in which the view layout, user navigation, and even the flow of data and control in the application can be defined graphically, according to the Web Dynpro meta-model.
Here, the integration of tools plays an important role. This is why SAP has drawn up its own communication framework, over and above the communication framework Eclipse offers as standard, so that the Studio tools can cooperate even more effectively.
Based on this common framework, the 6.40 release of the studio also integrates the various SDKs that have existed concurrently in the SAP NetWeaver technology platform environment. Some of the more popular SDKs that are being merged into the central SAP NetWeaver Developer Studio, include the Portal Development Kit (PDK) that helps the developer in creating contents for SAP Enterprise Portal, the SAP BI (Business Intelligence) components, and SAP MI (Mobile Infrastructure) which is the technology layer for mobile applications. SAP NetWeaver Development
In SAP's strategy for Java application development, SAP NetWeaver Developer Studio is only a first step. The next step is to create a comprehensive system for the coordination of the development process - the SAP NetWeaver Development Infrastructure - around the studio.
In Web AS 6.40, a Design Time Repository (DTR) has been added, to manage sources in distributed teams. Some of the other components that are in the offing are a Component Build Server (CBS) for automation of the build process, taking into account the dependencies between different versions of relevant components, and the Change Management System (CMS) for distribution and versioning of software components. The System Landscape Directory (SLD) is intended to provide an overview of the development landscape, the entirety of development, consolidation, and test and supply systems.
NWDI's prime objective is to provide optimal support for the coordination of large developer groups as well as the management of software products across multiple releases. This requires precise knowledge of the dependencies between the developed modules. For this purpose, SAP offers a sophisticated component concept - any software developed in Developer Studio can be subdivided into components. At the same time, a specific Perspective allows definition of the "public parts" of each component, that is, the units that can be used by other components. On the basis of these defined interfaces, NWDI can monitor the usage dependencies between the components and thereby automate the entire software life cycle.In this article, we have looked at the workhorse of SAP's Java environment. It is recommended that you download the SAP Developer Workplace trial version from the SAP Developer Network Web site, to familiarize yourself with Web AS Java. The workplace (https://www.sdn.sap.com/) consists of a 90-day stand-alone installation of SAP Web AS Java and SAP NetWeaver Developer Studio.
The next two articles will focus on application architects as we answer the questions: How can user interfaces be built with SAP's Web Dynpro technology? What is the specific role of Web services in the SAP application landscape?
We will then go on to explain how SAP consolidates its technology components (SAP NetWeaver) and see how new applications can be composed using SAP NetWeaver (xApps).
