Skip to Content

This is the second in a series of four blogs that describe SAP’s comprehensive approach to standards for enterprise SOA explaining how SAP’s business process platform uses standards to deliver business value.

The Delivering business value through a comprehensive standards-based approach to enterprise SOA – Part 1 explained how SAP’s approach differs from “merit badge” based approaches and the importance of considering technology and business semantic standards together.

This Delivering business value through a comprehensive standards-based approach to enterprise SOA – Part 2 provides an introduction to SAP’s approach to standards for Enterprise SOA describing SAP’s Standards Taxonomy which provides a way of categorizing and thinking about standards as well as covering the first category: “Technology Standards”.

The next two blogs will provide:


Now for the SAP’s approach to standards for enterprise SOA …

SAP’s Approach to Standards for Enterprise SOA

SAP’s approach to standards for enterprise SOA, that is embodied in the SAP NetWeaver Business Process Platform, is to first focus on evaluating the business benefit each standard can potentially deliver. In many ways, technology standards deliver a single value – they allow an enterprise service to be consumed from another environment. Technology standards do not address business semantics or rather how to use the information contained in the messages received and sent by a service. Only when combined with standardized business semantics can an enterprise service be used correctly in a composite application.  Business value is delivered only when a service is implemented in a business process platform built to an “enterprise standard” that delivers reliability, scalability, performance and security.

But currently there is a maze of standards where each individual specification or standard only addresses part of the challenge of interoperability. So it is important when implementing enterprise SOA, to rely on a software company, such as SAP, that fully understands how to navigate the labyrinth.

The SAP Standards Taxonomy

The SAP “Standards Taxonomy” (see Figure 1) is the SAP map of the world of standards. Just as a map shows how streets relate to one another and provides context and direction, the standards taxonomy is a method for identifying standards in terms of their purpose and relationship to one another [1].


The SAP standards taxonomy describes a comprehensive approach to the relationships and consists of four layers:

  • Layer 1 Technology Standards that are designed to help computer systems work together. These standards provide the foundation for openness and interoperability that are the basic underpinnings of SAP NetWeaver 7.0. They cover: Metadata Infrastructure, Messaging, Component Frameworks, and Foundation (Transport and Core Languages)
  • Layer 2 Languages for Defining Business Semantics. These languages, such as XML, WSDL and BPEL, provide a common vocabulary that can be used to create formal, standardized definitions of, processes, services and messages in a machine processible form. They provide the bridge between technology standards and business semantic standards
  • Layer 3 Business Semantics Standards. These are descriptions of individual “standard” processes, services and messages generally defined using the languages from layer 2. They are key to enabling companies to collaborate with each other Many are defined by vertical industry standards organizations designed to meet the needs of one industry. There are also important initiatives, such as UN/CEFACT, that cross industries
  • Layer 4 Common Standards. These are important standards that either describe how standards are used together or are standards that cut across more than one of the other three layers. Common standards include: Profile, Management, Security, Policy, Ontology and Development standards.

This rest of this second blog in the series will describe Layer 1 Technology Standards. The next blog will describe Layers 2 and 3 on Business Semantics, and the final blog will describe Common Standards.

Layer 1 Technology Standards – The foundation for Security, Reliability and Scalability

Technology standards provide the foundation for the openness and interoperability that are the hallmark of enterprise SOA. These standards are important for efficiently deploying business solutions and are often created within international organizations. SAP leads and participates in these organizations, as well as in the development of these standards. SAP, for example, is part of the World Wide Web Consortium’s (W3C) advisory board, which defines the technology standards for the Web, including HTML, XML, and core Web services specifications including SOAP, WSDL, WS-Addressing, and WS-Policy.

SAP also leads a number of SOA standards at the Organization for the Advancement of Structured Information Standards (OASIS) that support critical features in the implementation of enterprise SOA. These standards are reflected in the core Internet connectivity and Web services interoperability capabilities of SAP NetWeaver. This interoperability is also rigorously tested in the Web Services-Interoperability (WS-I) organization, chaired by SAP. WS-I promotes consistent and reliable interoperability among Web services across platforms, operating systems, and programming languages.

Enterprise SOA needs a business process platform on which enterprise services and composite applications can run. The business process platform also needs the technology standards described in this section to make it easy to connect to an enterprise service no matter whose solution was used to build it.

There are four parts to Technology Standards (see Figure 2): Metadata Infrastructure, Component Frameworks, Messaging, and Foundation.


Metadata Infrastructure

Software is built from multiple components of many different kinds. In order to use these components correctly, solutions need to find, keep, and access information about them. This information about components is called “metadata.”  Machine-readable metadata is essential to model-driven development approaches such as Model Driven Architecture, which SAP NetWeaver uses.

Model Driven Architecture (or MDA) streamlines software development, deployment, management, and integration, making heavy use of models and metadata throughout the software lifecycle.  The ultimate goal of MDA is to be able to directly execute business process models, by connecting the models to executable, model-driven services.

Metadata Infrastructure standards help by providing standard ways of defining and using metadata (see Figure 3) and the explanation below.


They fall into the following main areas:

  • Metamodeling Standards. A Metamodel defines the metadata needed for a particular kind of component. MOF, or “Meta Object Facility” is an Object Management Group (OMG) standard that provides a metamodeling language that is used to define the Metadata that should be kept for different types of components. For example, MOF is used to define the kinds of metadata needed to describe a business object, including the name of the object, the definitions of its properties, the definitions of its relationships to other objects, etc. MOF’s metamodeling language can also be used to define the kinds of metadata needed to model business processes, and to define metadata that describes how a component relates to a business process.
  • Metadata Repository Standards. Repositories that understand MOF can store any kind of metadata about a component, if there is a MOF definition of that kind of metadata.
  • Metadata Interchange Standards. It is often necessary to extract information out of one metadata repository so that it can be imported into another or into a tool. XMI, or XML Metadata Interchange, is a standard closely related to MOF that defines how to use XML to represent MOF-based metadata about a component, so that the metadata can be easily moved among repositories and tools.
  • Standard Metadata APIs. JMI, or Java Metadata Interface, defines how to represent MOF metadata as Java objects.  The standard defines rules for generating Java APIs that can be used to store, access and manipulate MOF Metadata about a component.

Most information systems store or create their data in multiple databases, XML documents, and files. Effective management of this heterogeneous data requires integrated metadata that provides robust information about database schemas, XML schemas, data transformation rules, data analysis rules, and so on. The Common Warehouse Metamodel (CWM) is a standard that uses MOF to define the metadata that needs to be maintained for these components of information systems. It also defines an XMI format that tools can use to exchange these kinds of metadata. CWM makes it easier to create Business Intelligence solutions that can manipulate data across multiple databases, files, etc.

Another important metadata standard is UDDI, which provides for the discovery and retrieval of information about services. Composite application development tools can use UDDI to discover enterprise services needed to build a composite application.

Component Frameworks

Component Frameworks are used for two main purposes:

  • To define how to use enterprise services together when composing an application, and
  • To create the code and business logic for an enterprise service component.
  • The main standards used to define how to compose services together are:
  • Service Component Architecture (SCA), which simplifies the creation, composition and deployment of services by allowing configuration of components separately from the code, and defining a simple model for assembling the components together, and 
  • Service Data Objects (SDO), for uniformly processing the data objects accessed by a service across various different frameworks such as for UI, application and persistence.
  • Java Platform, Enterprise Edition 5.  Java Platform, Enterprise Edition, Java EE (formerly J2EE) is a critical component framework to use when creating new enterprise services. In particular Java EE 5 offers many advantages and simplifications when compared with earlier versions of Java, resulting in higher developer productivity.

SCA and SDO enable specification of service components and data objects at a relatively high level of abstraction while defining bindings to relatively low level technologies, such as Java, C++, Web services, and so on.  This enables service clients and servers to be composed together even when they are implemented over different low level technologies.

SAP NetWeaver 7.0 implements Java EE 5.

Messaging Standards

Communication with enterprise services occurs through messages that are sent to and from the enterprise service.

How the message is sent depends on how and why the enterprise service is being used.

Java Messaging System (JMS)

When used in a single application, a programming-language-specific method of sending messages such as the Java Messaging System (JMS) is likely to be used. JMS is part of the Java Platform, Enterprise Edition component framework. The benefit of JMS is that it provides a standard easy-to-use API that a service can use for sending and receiving messages. However it relies on both the sender and receiver solutions both being implemented using Java and typically part of the same IT system.

Web Services

If the messages are being sent to a service that is part of a separate application or that is run by a separate business, then Web services are the better standard to use as they work over the Internet. This means that the sending and receiving applications do not have to use the same technology as long as they follow the same messaging standard. Standardization also makes it easier to create messaging middleware that does the “heavy-lifting” of sending and receiving messages.

Since the message may need to be sent over the internet, messaging standards need to ensure that the message can be sent securely and reliably when needed. To provide for this there are several Web services messaging standards that mirror closely the approach used when sending messages in the real world:

  • Envelope Standards. These are standards that define the structure of the electronic envelope into which the content is placed, e.g. an electronic document such as an XML order. Critical standards are the Simple Object Access Protocol (SOAP) which defines the structure of the envelope and Message Transmission Optimization Mechanism (MTOM) which extends SOAP to define how to create a SOAP envelope that contains multiple different electronic documents in any format – not just XML
  • ElectronicAddress Standards. Real world envelopes have an address  on them that can be used to route the message to the correct destination. In Web services, the WS-Addressing standard provides the equivalent function
  • Message Delivery Standards. These are standards that ensure that messages are delivered reliably and securely.  Key standards include:
    • The WS Security standard that defines how a message can be encrypted to ensure privacy, as well as digitally signed so that the recipient can check who sent the message and be sure that the message has not changed during transmission – Security will be discussed in more detail in the fourth blog; and
    • The WS Reliable Messaging standard that provides a standard way of making sure that a message is delivered with certainty as well as in the correct order.


Web Services Profiles

The Web service messaging standards offer many different options for how they can be used. To makeimplementation simpler the Web Services Interoperability Organization (WS‑I) has developed “profiles” that define a subset of the standards described above as well as describe how they should be used together. These profiles include: theWS-I Basic Profile that defines how SOAP should be used with other standards; the WS-I Basic Secure Profile that describes how messages should be secured using WS Security, and the WS-I Reliable Secure Profile (WS-I RSP) that defines how WS-Secure Conversation,WS Security and WS Reliable Messaging should be used together. WS-I RSP is an important specification that should be finalized towards the end of 2007. More detail on WS-I will be provided in the fourth and final blog.

Foundation Standards

Foundation standards, as the name suggests, are low level but essential standards that are used by many of the other standards described in this paper. Many will likely be familiar, but they are included here for completeness.

Programming languages are one of the most important foundational standards. SAP NetWeaver 7.0 provides support for both ABAP and Java providing a single environment in which solutions built using both SAP technology and Java can run.

SAP NetWeaver 7.0 also provides support for other foundation standards in three main areas:

  • Web standards, such as HTML to define the content of web pages in a Web browser; HTTP, the transport protocol that is used to transport web pages; as well as SSL and TLS that are used with HTTP to keep the information in the web page private
  • “Mark up” languages that are used to define other languages. Of these, the most important is XML and it’s newer variant XML Schema that are used to define the majority of the other definition languages including service definition languages such as WSDL and process definition language such as BPEL (see Languages for Defining Business Semantics for more information on WSDL and BPEL)
  • Database Access Languages, the most important standard is SQL or Structured Query Language that is used to retrieve and maintain data in databases.


The next two blogs in the series …

The next two blogs in this series will describe the remaining categories in the SAP Standards Taxonomy:

  • Part 3 – A description of the next two categories: “Languages for Defining Business Semantics” and “Business Semantics”
  • Part 4 – A description of “Common Standards” that cross both technology and business semantic standards.

   [1] Like all good maps SAP’s Standards Taxonomy is available at varying levels of detail. If a deeper level of detail is needed on the standards that SAP considers important then visit the SAP Developer Network (SDN) Standards pages at

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply