Scott Campbell

Subscribe to Scott Campbell: eMailAlertsEmail Alerts
Get Scott Campbell: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, SOA & WOA Magazine

J2EE Journal: Article

Web Services Strategy - SAP Platform

It's not your father's SAP

Step 1: Start Using SAP's Web Services: See Figure 1

This is the obvious first step to realizing the ESA vision. In the layered architecture described above we begin with foundational technology and basic application interface-level services. These are our building blocks. Today all SAP applications can expose or consume Web Services through the Web Application Server or as endpoints modeled in Exchange Infrastructure. This means any .NET or Java developer can be an SAP developer from the standpoint of integrating with the SAP business applications. No longer do you have to know all the technical details around the ABAP, BAPI, iDoc, and RFC technologies that have made SAP applications so difficult to integrate in the past. Likewise, ABAP developers can now construct and expose Web Services using the Web Application Server. Essentially any out-of-the-box or custom SAP function module can be deployed as a Web Service.

As mentioned, these Web Services provide value at the basic application interface level, or as foundation technical-level services such as user management and security services. Examples might be "update invoice line item #2," "convert dollars to euros," or "determine if Jill can view the invoice." NetWeaver also offers public and private UDDI servers for creating a directory of Web Service definitions. In addition there is logging and tracing support for Web Service invocations. Finally, the NetWeaver Developer Studio includes tools, wizards, and utilities to simplify the entire Web Services creation and deployment process.

Armed with this level of Web Services support developers can easily integrate SAP and non-SAP applications using their preferred development language.

Step 2: Leverage XI to Build Enhanced Services and Digital Process Execution Models

With a full complement of foundational Web Services in place, NetWeaver can be used to define more coarse-grained composite services. Exchange Infrastructure enables the kind of modeling and composition where services can be woven together to do larger units of work. More importantly, the compositions themselves can be exposed as Web Services for consumption by other applications. An example of services at this level could be "pay invoices" or "optimize purchase discounts."

The XI integration repository captures the design model. A complementary integration directory is used to capture the deployment model with specific information about system landscapes and endpoints. Finally, the integration engine controls the runtime behavior by executing service choreography in a stateful manner as well as providing real-time activity monitoring.

As mentioned above, SAP and IDS Scheer have partnered on tools to convert high-level process models developed by business analysts into digitized process execution models in XI. Expect this alignment to be significantly improved over time. The implication is that composite Web Services will more closely match real business process activities.

Step 3: Define Your Enterprise Services: See Figure 2

In step 1 we identified our technology and application integration level building blocks and exposed them as Web Services. In step 2 we wove them together to create more coarse-grained Web Services that span functional and application boundaries to perform larger units of work. From a technical standpoint these are the steps needed to create the enterprise-grade services that are part of SAP's ESA vision.

However there are more than just technology considerations for having proven Enterprise Services. We've identified eight characteristics that make composite services valuable Enterprise Services. They are:

  • Locatable - "I didn't know the service was available!"
  • Reachable - "The service used the wrong protocols."
  • Well Documented - "I couldn't figure out what the service did!"
  • Usable - "The service was too narrowly defined for my business needs."
  • Policy Based - "The service didn't support my non-functional policy requirements."
  • Adaptable - "The service was too hard to change for my needs."
  • Managed - "I didn't trust the service availability for my SLA."
  • Encouraged - "I had no incentive to use the service."

More Stories By Scott Campbell

Scott Campbell is president of MomentumSI, a professional services firm specializing in platform-ready, service-oriented enterprise architecture and business process management solutions. Prior to joining Momentum in 1998, Scott helped open the Houston office for DiaLogos, Inc., and he previously held various positions in product marketing and IT at 3M.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Satish 08/03/05 08:24:16 AM EDT

An excellent article at the overview level. Very neat, crisp and simple! Thanks!