"Shaken, not stirred!" is not only a quote of a well-known british secret service agent movie character, but it is part of a recipe for preparing a Martini, which is, so to speak, an alcoholic beverage. Every bartender, chef and cook knows that the best ingredients and the best china cannot save a dish from a bad recipe. If the bartender does not mix the Martini by shaking it, James Bond might be in a bad mood - and that is even worse for the bad guys in the movies (much to the pleasure of the movie goers, I must admit).
Well, and if you, as the "bartender" (read: "developer") do not mix the Business Objects and UI patterns with the right "recipe" (read "service"), you might turn out to be not only an ex-bartender, but also the bad guy (at least the developer's looks are said to be already stereotypically close to that: unshaved, uncombed, tired, small (did I hear "mean"?) eyes and bad breath from too many pizza-with-onion late-evening-dinners in front of the error-messages). We all know our little "James Bonds" - the users - who are not only extravagant in their demands ("Shaken, not stirred!"), but also extreme in the usage of our fanciest tools ("You did WHAT to our only invisible car protoype?").
What's the moral of the story for you? Take the Service Modeler and do the right mixing and shaking. If you sing a song along with it or dance to it, it's your artistic freedom. The base-functionality is provided for you and not part of your worst nightmares anymore.
The Concept
The Service Modeler is part of the Composite Application Modeler plug-in for Eclipse. Similar to the Business Object Modeler it consists of several editors, where you a) create and compose your service, b) maintain the service metadata and c) finally receive a generated coding (an EJB and interfaces), in which you can add your own custom coding.
But let's get into details:
a) Services will be able to use Business Entity Services (the services that are wrapping each Business Object) and other services, be they composed services themselves or Web services, for example. This helps to reuse services and accelerates development.
b) Maintaining the service metadata includes descriptive information of the service itself, the functionality that will automatically be generated (authorization checks, logging & tracing,...) and the way the service exposes itself (as Web service, the interfaces,...). The (visual) mapping of inbound and outbound plugs of used services and definition of the plugs for the service itself can be done here. A similar approach is used by Web Dynpro.
c) The generation of the service creates classes with EJBs and Interfaces. The service body allows you to enter your custom coding and extend the service with your own business logic. Actually the vision here is that future versions of the Service Modeler contain a rule & formular wizard-like concept that allow the specification of logic in a non-programmative style (for better understanding, a reference: the SAP data warehouse solution BW uses a similar approach for update- and transfer-rules).
After the creation a complete integration in the Web service infrastructure and service architecture of SAP NetWeaver guarantees the update of the UDDI, the Web service directory. This integration allows much easier use of the services by UIs, as the sophisticated translation of service data-types to UI fields is not a matter for you anymore.
A more detailed introduction to the Service Modeler, peppered and cherried with some screenshots, will follow at some later point in time.
Conclusion
You might not necessarily experience passionate kisses at the end of the programming adventures, as traditionally happens between James Bond and the obligatory beauty, but you might have the satisfaction that the kind of challenges in building services, moved to a different stage. With the Service Modeler, basic coding tasks are automatically included in the coding generation and your focus stays on the logic, not the infrastructure for the logic.
It's all about the right recipes. Here's one for the Martini (to complete the title of this Weblog).
