20 Nov 2003
Experience with New Technologies
Recently I went for a meal in a Greek restaurant with my daughter. There were all kinds of delicacies on the plate of appetizers, including small peppers. As I was looking at the wine menu, I heard a scream followed by pitiful crying, which I was not able to soothe. It was clear what had happened, but why should it happen at all? Usually she is so careful and suspicious about new and unknown food. But this time she was apparently misled by past experience with mild peppers. We both clearly felt the results: she from the burning pain in her mouth, and I from the reproachful look. Both must have been about equally painful.
Experience never seems to be a reliable advisor when apparently similar situations are not at all alike. This is also true when new technologies appear on the horizon. When the topic of Web services became popular about 3 years ago, you could observe various reactions.
Some people reacted in a bored manner and pointed out that the only relevant feature of Web services was the Simple Object Access Protocol, called SOAP. Anecdotes described the parts of the name:
Simple because of the missing features
Object to hide the fact that only primitive data types were supported
Access to point out that no access or security mechanisms were included.
Nobody had any objections to the word Protocol, but there were enough of them already on the market. In other words, the similarity to other existing technologies such as CORBA, RMI and other middleware technologies seemed so great that it was not worth wasting one?s time on Web services.
A great mistake, as we now know. The example of Web service technology shows that successful technologies might not always satisfy the original expectations, but in the long run they develop into a primary factor in certain areas. The fact that many of their features are similar to existing technologies is no reason for not becoming familiar with the new technologies.
Pure technology does not offer much added value - we would only have limited enjoyment from a fantastic CD player if there were only records. It is similar with Web services. Technically, they offer many possibilities. But how can we create enterprise services in which parts of complex solutions such as CRM systems are provided as effective services in a standardized manner? This brings us to the keyword "services architecture", the latest, though not new, trend in our industry.
At the SAP TechEd conferences in Las Vegas and Basel, many talks showed how you could create and use a new generation of flexible solutions called xApps based on the SAP NetWeaver™ platform and Enterprise Services Architecture (ESA).
Anyone who wants to ignore this trend will easily find a reason to do so. Here are a few tips:
You could claim that you have always built xApps by embedding PowerPoint and Excel objects in Word documents and thus build new services from other applications. Occupying yourself with this topic would therefore be a waste of time.
Another efficient trick would be to wait for the release of the SAP Composite Application Framework, which is to appear in a few months, and which will make it even easier to develop xApps. This would enable you to justify your waiting for Release 2 or perhaps 3 of this framework.
Those of you, however, who want to become familiar with the fundamentals of how services are created, shipped, and used in the SAP NetWeaver platform right from the beginning should have a look at the Sneak Preview of the SAP Web Application Server. It is available for download with the development tools of the SAP NetWeaver Developer Studio, including Web Dynpro, or can be ordered as a CD. Numerous tutorials and examples of coding guide the developer through the necessary steps and point out important aspects of the service orientation when creating custom applications.
For example, within a few minutes you can generate an e-mail client supported by a Web Dynpro model that uses a public Web service to send e-mails. In another example, Web Dynpro accesses RFCs, thus making it possible to access R/3 data and display it in a Web application.
Web Dynpro supports the scalable Model View Controller (MVC) design pattern. First a model is created which defines what kind of services should be used: RFCs, Web services or any other software components that are described in XMI format.
The screenshot of Web Dynpro (Figure 1) shows how to choose between different services:
Then the location of the service and other required parameters need to be specified:
Afterwards, the model representing the service is available and ready to use!
Once the model has been defined, the type of service or its origin is fully transparent for the developer. All models behave in the same manner and are subject to the same programming paradigm. Precisely this is the basic concept of the Enterprise Services Architecture: different components of entirely different origin have a unified interface that is described according to given rules. These can be merged easily and flexibly to create meaningful applications.
Does this sound familiar? Haven't new applications been created for a long time by accessing the application logic of existing RFCs or BAPIs? Of course, but the model-based architecture described here is more general and permits you to integrate the most varied service technologies. A small difference - like the one between mild and hot peppers ...