GRC
HR
SCM
CRM
BI


Article

 

SAP's Strategy Toward an Integrated, Full-Featured Java Development Environment

by Karl Kessler | SAPinsider

January 1, 2003

by Karl Kessler, SAP AG SAPinsider - 2003 (Volume 4), January (Issue 1)
 

ABAP developers have seen this platform mature over the last decade, to the point that ABAP provides a highly integrated repository-based environment, and even includes the tools — the ABAP Workbench’s Web Application Builder, for one — to fully support fast and easy web development.

Then, with Release 6.20 of SAP Web Application Server (Web AS), SAP delivered a companion Java runtime platform — the SAP J2EE Engine. Now, with Web AS 6.30, SAP is working to bring some of the design strengths and features of ABAP’s server-based environment to a client-based integrated development environment (IDE) for Java. This article introduces developers to the strides SAP is making — including a brand-new, custom-made Java IDE — toward easier, more powerful development tools for Java with the SAP J2EE Engine in SAP Web AS 6.30.

SAP’s Approach to Easy Java Development with SAP Web AS 6.30

Java developers generally prefer IDEs with a client-based environment, residing on the local PC where they can implement their Java applications and test them locally. Most Java IDEs also provide the tools, editors, and wizards to help you develop applications that are strictly conformant to the basic J2EE programming model, which typically divides enterprise applications into several parts and corresponding technology: user interface logic handled by JSP pages or servlets, business logic implemented via Enterprise JavaBeans, and a database layer that allows access to relational tables using JDBC or some higher-order persistence model such as CMP.1

Thanks to SAP Web AS’s J2EE compliance, there are Java IDEs on the market that can be used in conjunction with SAP’s J2EE Engine. In Release 6.20, SAP offered add-ons, such as the BAPI Browser, for these Java IDEs. However, there were some common issues in SAP design scenarios that are not fully resolved within a pure J2EE model:

  • Local development is fine. But if an application runs on a local developer’s machine, it does not necessarily run on a central J2EE server shared by several developers.

  • Most Java IDEs get their Java sources from file-based versioning systems that lack repository features, which makes distributed development rather difficult.

  • Although you can provide add-ons to existing Java IDEs, these add-ons typically do not get full control on the developer’s workspace.

  • Many dependencies between the different parts of a Java application — user interface, business logic, and database layer — are not tracked automatically by current Java development environments. Typically, in large projects, deploying incompatible archives to a J2EE server can actually bring the whole J2EE server down.

It soon became clear that an integrated, repository-based environment could not be fully realized simply as an add-on to a Java IDE. However, most issues in this list are already resolved, or simply do not arise, in a purely server-based environment such as ABAP.

As a result, SAP’s approach toward achieving an integrated development environment in the SAP Web AS is to take the strengths of a local, file-based designtime environment and combine it with strong server-side integration comparable to the ABAP environment. And, with SAP Web AS Release 6.30, SAP decided to develop its own Java IDE, built on Eclipse (www.eclipse.org).2

The new SAP Java IDE is one key element of SAP’s effort to make a better-handling and more powerful design environment, touching all six major aspects of web development for Java:

  • Web Dynpro for the user interface layer

  • Portable database access for the database layer

  • J2EE features that extend the business layer

  • Java Dictionary for greater consistency of databases and user interfaces

  • New infrastructure services — the Designtime Repository and Component Build Service — for version control and automatic build

  • Automatic configuration of the development environment

Web Dynpro

To start, consider the J2EE model’s user interface layer: JSP and servlets do not provide the level of abstraction needed for powerful applications. Most applications written in JSP are browser-dependent and difficult to maintain. In a plain JSP application, layout and Java code are typically mixed, making it really difficult to quickly adapt a user interface to changing requirements.

To address these concerns, SAP developed a web user interface model called Web Dynpro, which runs inside SAP’s J2EE Engine. Web Dynpro offers a model-driven, declarative approach to web UI development. Many changes to Web Dynpro applications can be made by modifying the model the application is based on — but without having to rewrite the business logic, as you would with many plain JSP applications.

SAP now also offers development tools designed for the Web Dynpro implemented as Eclipse Plug-Ins. These plug-ins offer a highly interactive and graphical user interface experience, including an application modeler, Web Dynpro Perspective (see Figure 1), that helps model Web Dynpros graphically.

Figure 1 Modeler for the Web Dynpro

Portable Database Access

Just as the naive use of JSP can lead to unportable web user interfaces, the direct use of JDBC is inherently database-dependent, leading to portability problems of its own. One of the major milestones in ABAP technology was the introduction of a portable database access layer though Open SQL. Now, with Release 6.30, Open SQL is available for the Java technology stack as well. Java applications can be written in a database-independent fashion — whether using a direct relational interface or an object-based interface such as CMP. All higher-order persistence models are piped through the Open SQL for Java channel.

Here, too, SAP now offers support with Eclipse Plug-Ins. From the tool-support side, a plug-in offers a precompiler based on SQLJ to embed SQL statements in Java code directly, along with a debugging environment where you can test your database access on the embedded SQL level rather than on the compiled level.

The Business Layer

If you install Eclipse on your machine, you will find only the tool environment for the standard edition of the Java 2 Platform (J2SE). From here, you can write, test, and debug Java code, but without access to a J2EE server. To integrate these functions into the J2EE Engine, SAP is currently developing a J2EE perspective — also an Eclipse Plug-In — that allows you to develop all parts of a typical J2EE application, including Enterprise JavaBeans and enterprise archives, which are then ready for deployment onto the local J2EE engine.

The J2EE perspective is the starting point for deriving web services. Since Enterprise JavaBeans provide method interfaces, it is quite natural to use this as a basis for web service definition and proxy generation. However, since Enterprise JavaBeans should not be exposed directly to the web, SAP’s J2EE perspective allows you to derive web service definitions where only a set of methods is exposed as the interface to the outside world.

Java Dictionary

The new Java Dictionary is another example of taking the ABAP approach and developing its match on the Java side. In the ABAP world, the ABAP dictionary is the central place for defining data type definitions, and drives the activation of dependent development objects such as web dynpros and the definition of underlying database tables. J2EE, on the other hand, gives little information about database and user interface consistency.

The Java Dictionary helps to define central data types and user interface services (input validation and value help) that are used in Web Dynpro applications.

Java Development Infrastructure

The strength of ABAP’s development infrastructure is based on two things: First, all development objects are centrally stored and versioned, making it easy to identify the active version of each development object. Second, if the active version is changed, the ABAP runtime environment takes care to activate dependent development objects in what I like to call a “lazy” fashion — that is, designed for the ease of the developer. In ABAP, when the dependent development object is called, the runtime environment instantly checks for consistency and will eventually recompile the dependent development object. The environment takes care of it for the developer.

It should be clear that this approach cannot be followed in the Java environment. This would imply adding proprietary extensions to the J2EE environment — a violation of the J2EE standard. Instead, SAP has set up two infrastructure services that provide similar programming ease: the Designtime Repository and a Component Build Service.

Designtime Repository

To overcome many of the limitations of file-based versioning systems, SAP is developing a Designtime Repository for all kinds of development objects required in the Java development process. Java sources, XML files, etc., are stored in a hierarchy of files and folders that are visible for client-side tools through the WebDAV and DeltaV protocol. Each file or folder has its own version history. The definition of workspaces allows you to group sets of files in a particular version for a specific purpose (e.g., development, maintenance of delivered releases, etc.).

Developers access the Designtime Repository simply by checking out source files or synching files for read access to their local hard disk. After local development and test, they check their changes. The Designtime Repository manages distributed versions and is capable of resolving version conflicts when integrating changes from other workspaces.

Component Build Service

The Component Build Service is then responsible for producing runtime objects for the sources in the Designtime Repository. The ultimate design goal of the Component Build Service is to automate the build process in an incremental fashion, comparable to activation of ABAP development objects.

Many Java build tools tend to build everything from scratch, even when only a small change is made. In a central test environment this means very long repair cycles, since complete archives need to be rebuilt and redeployed to the central server. A better approach is to manage the dependencies between development objects directly.

With SAP’s component model for Java programming, if a new Java source is created, the source must be assigned to a development component (just as an ABAP program is assigned to an ABAP package upon creation). Thus, development components are containers for development objects — not only for Java sources, but also for other categories, such as table definitions from the Java dictionary, or Web Dynpro applications that consist technically both of XML files and Java sources. Components may be nested to allow for structuring large Java applications. Each component defines the elements that are visible in “public” parts accessed by other components, much like ABAP package rules.

The assignment to components makes Java applications much more maintainable and is the driver of the Component Build Service. When a component is activated, the system checks where dependent components need to be rebuilt. Only if all affected components are (re)built successfully are they redeployed on a central server. This strict approach ensures that only compatible archives are deployed on the server.

Automatic Configuration of the Development Environment

Anyone who has worked on a Java project knows that setting up a consistent environment on a local developer’s machine can take a serious amount of time. Getting the right sources is usually done by accessing a central versioning system; however, getting the supporting Java archives is typically done manually by copying them from a build machine. This leads to situations where different and often incompatible versions of development tools are in use.

The solution to this problem in SAP Web AS 6.30 is based on the compatibility of development components, with compatible versions maintained in a central configuration. If a developer starts his or her local Java IDE and checks out files that belong to a given workspace, the IDE takes care to download any required archives, or to update them if changes have been activated in the meantime. Thereby, developers are notified, and the incompatibilities and inconsistencies that are so difficult to track later in a central environment are removed from the local environment. Figure 2 shows the Java development process in SAP’s Java infrastructure.

Figure 2 Development Process in SAP Web AS Java Infrastructure

Summary

SAP’s strategy toward a Java development environment for Release 6.30 of its Web Application Server is technically based on Eclipse technology, and helps developers more fully leverage the J2EE standard. SAP delivers plug-ins to Eclipse for all major aspects of web development, such as Web Dynpro, EJB development, web services, and Java persistence.

SAP’s Java IDE is designed for a local, PC-based development environment, but is embedded in a development infrastructure that mediates between the local developer’s machine and the central J2EE server by means of its central repository and its build and deploy services. The component model for Java applications has many similarities to the ABAP package concept, and provides the basis for many of SAP’s infrastructure services, such as incremental activation of changes and automatic configuration of the local IDE.

For More Information

Eclipse and Eclipse Plug-Ins will be delivered with SAP Web AS 6.30. For further details, visit http://service.sap.com/technology.


1 Container managed persistence.

2 Eclipse is an open-source, Java-based framework for IDE development, based on technology donated by IBM in 2001. Many independent Java tool vendors are now delivering plug-ins for the Eclipse platform


Karl Kessler joined SAP in 1992. He is the Product Manager of the ABAP Workbench and the SAP Java IDE and is responsible for all rollout activities. You can reach him via email at karl.kessler@sap.com.

 

 

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ