WS-I Sample App Blog Series: Basic Design Decisions

[Former Member]

In the last installment of the WS-I Sample App blog series we discussed the basic architecture of the sample application. In this installment we’ll illustrate how we decided to implement the Sample Application on the SAP NetWeaver platform.

Java or ABAP?

Perhaps the first thing to point out is that the NetWeaver platform supports two technology stacks, Java and ABAP. Some of our competition like to point out that ABAP is a proprietary language, alluding to the fact that SAP's solution is closed. While it is true that ABAP is a proprietary language, it is patently false that SAP is a closed system. SAP has shipped its source code to its customers years before that was the 'in' thing to do. The simple fact is that ABAP was invented by SAP for SAP and its customers because there was no other alternative at that time, and if you think we're going to abandon ABAP and the 30,000 customers who run it because other higher level languages are now 'in', you're crazy. Java is one of these 'in' languages though, and it is critically important to support it in the industry, which is why SAP added Java to the solution. SAP's Java stack has the benefit of being designed by enginers with many years of experience developing enterprise software, which has resulted in features that go above and beyond what you'll find in other Java development environements. To illustrate some of these features we decided to focus our Sample Application efforts on the Java stack, and specifically use the new open and Eclipse based SAP Netweaver Developer Studio. We were also interested in learning more about how the new JDI (Java Development Infrastructure) would work for developing an enterprise application as a team, so we adopted it as a means for coordinating our development between California (where I'm located) and Germany (where my colleague Martin is located). For those of you interested in a more detailed look at JDI, this article should prove to be an interesting read.

Basic Architecture: MVC

The Sample Application lends itself well to a simple Model-View-Controller design pattern. Within the Netweaver Developer Studio one can find all the components necessary to for such a pattern, from database design through business logic and up to the user interface layer. What follows is a brief description of each layer.

Database Design

For the database layer we choose to use SAP’s OpenSQL technology which enables application developers to design the data model of the application without knowledge of the underlying database. Certain database providers (ahem, Oracle, I’m looking at you) have ‘eccentric interpretations’ about how databases should function. For example, Oracle treats a string of zero length, i.e. an empty string, or “”, as a NULL value. In my opinion (and the opinion of everyone I've talked to with at least a basic computer science degree), NULL means NULL, i.e. the absence of anything and certainly not the presence of a zero length string. This caused much consternation in a past life of mine while porting an application to an Oracle database. I’ve singled Oracle out here, but truth be told, all database providers are likely to have their own intricacies (hopefully none are this obviously wrong) and SAP’s OpenSQL technology is intended to handle these issues in a manner transparent to the application developer. For a full description of the Java Persistence layer, please see this document.

Fortunately the majority of the actual database design work was laid out for us in the Sample Application Architecture document (found here). We simply had to use the tools in the SAP Netweaver Developer Studio to map the data model into the correct columns of the correct tables, which, given the simplicity of the Sample Application design and the ease of use of the tool, proved to be a relatively straight-forward task. Once the database tables had been defined, it was a matter of a few clicks to generate the entity EJBs that would be used to access and manipulate the data in the tables from the Java layer. SAP offers a full step-by-step tutorial of how to create entity beans.

Business Logic

The requisite business logic defined in the Sample Application also needs a place to live, and the logical place is obviously as a web service (this is a WS-I Sample Application, after all). At the time of this writing the NetWeaver platform didn’t support contract first development, so this step could have been a bit easier. It does seem rationale to me, however, to focus on being able to generate WSDLs for external consumption first so that companies can expose the functionality that that they already have as services, and then follow up with designing new services. I was assured that contract first development is coming in the next release. Whereas it would have been nice to just point to a WSDL and have it generate skeleton code for the Java classes that I would need to implement, the Sample Application interfaces were relatively straightforward and implementing them directly in Java and then generating the WSDLs wasn’t a very big leap for me to make.

After I’d implemented the business logic in the appropriate EJBs and generated the Java Proxies for each, it was simply a matter of 'hooking them up and making them run right' (to borrow from school house rock). Again, this was a few simple clicks to ensure that the code that wanted to invoke a web service had a reference to the library where the generated proxy classes were contained. The Design Time Repository (DTR) aspect of JDI helps in these efforts tremendously, and makes it virtually impossible to run into the all too common NoClassDefFound Exception at runtime.

User Interface

Web DynPro is the new state of the art SAP NetWeaver programming model for User Interfaces. It allows for a clear separation between the business logic and the display logic. The tools provided by the platform allow for the creation of complex user interfaces based on the metadata model of the application, which is independent of the rendering technique that is used at runtime. I found the development of the Web DynPro part of the equation to be the most challenging, but this was primarily due to my relative inexperience in developing User Interfaces. We’ll dive deeper into the details of how Web DynPro was used in the Sample Application in a later blog in the series. For now, you can click here to get a better understanding of the Web DynPro architecture,and here is a very detailed how-to guide.

Extra Platform Features

In addition to the basic MVC design paradigm that I’ve described above using the Java Web Services aspect of the SAP NetWeaver platform, we wanted to incorporate as many of the standard NetWeaver features as we could for illustrative purposes. Two of these features that proved to be the most useful were the incorporation of the UME (User Management Engine) for security as well as the standard logging and tracing utilities.

Security

Security is an important part of any enterprise application, but in the case of the WS-I Sample Application there are actually predefined user roles that are to be used for the scenarios. This also was integral in paving the way for the implementation of the BSP (Basic Security Profile) aspect of the Sample Application (covered more thoroughly in a future blog) which used certificates for encrypting and signing the messages that were sent between the various web services.

logging and tracing

The logging and tracing capabilities of the platform enabled us to more easily debug the solution when testing the scenarios with other vendors. It is also obviously possible to step through the execution of the code by attaching a debugger to a running instance of the server, but when testing interoperability with other vendors it is very useful to have a log/trace file that can be used after the fact, and also shared with the other vendors.

These are platform features that one would expect from any platform provider but the ease of use in setting up the scenarios on the SAP NetWeaver Platform was remarkable.

Conclusions

Hopefully I’ve been able to show the major aspects of the design and implementation strategy that we used while implementing the WS-I Sample Application on the SAP NetWeaver platform. This was meant as a high level overview, providing the basic resources that one will need to know about before going into detail. My colleague, Martin Raepple, will now pick up the pen and dive deeper into the details, illustrating in a more step by step fashion how each of these areas were put together to form complete Sample Application that not only illustrates the interoperability of WS-I profiles for SAP, but also many of the new features of the SAP NetWeaver platform.