Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

This is the third 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 ... explained how SAP's approach differs from "merit badge" based approaches and the importance of considering technology and business semantic standards together. The Delivering business value through a comprehensive standards-based approach to enterprise SOA - Part ...provided 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 Delivering business value through a comprehensive standards-based approach to enterprise SOA - Part ... provides a description of the next two categories:

  • "Languages for Defining Business Semantics" these are formal languages that are used to define semantics in the same way that English is a language that is used to express ideas
  • "Business Semantics" which are actual definitions that are written using the language, e.g. English.

The Delivering business value through a comprehensive standards-based approach to enterprise SOA - Part ... will provide a description of "Common Standards" that cross both technology and business semantic standards.

Now for the section on "Languages for Defining Business Semantics" ...

Layer 2: Languages for Defining Business Semantics - Promoting the Use of a Common Vocabulary

These languages are used to create formal, standardized definitions of processes, services and messages (see figure 4).

For example, WSDL is a service definition language that provides a means of describing Web services in a technology-independent manner. These languages provide the bridge that allows technology and business semantics to evolve independently of one another.

To leverage enterprise services, common languages and vocabularies are needed that can be understood and used by all parties when designing, provisioning, composing, and consuming enterprise services.

These kinds of languages also allow for the expression of the business contract that defines the obligations of an enterprise service provider. Rigorous specification of a contract helps ensure the business integrity needed to develop and integrate composite applications.

The following sections describe the standards for the languages that are used to define the business semantics for processes, services and messages.

Process Definition Languages

Process definitions describe a business process and the sequence and conditions (called an orchestration) in which enterprise services must be executed to perform the process.  For Business Process Experts (BPXs), the Business Process Modeling Notation (BPMN) is the critical standard, as it provides a widely-supported, business-oriented graphical way of defining the sequence of activities and conditions that constitute a business process.

In order to make a business process model executable, there is also a need for a language that process architects can use to specify executable processes and connect the activities in the business process to services capable of executing those activities. The Web Services Business Process Execution Language (BPEL) is an important standard for this purpose that introduces a model for executable processes based on Web services.

BPEL focuses on composing Web services. Yet not every activity in a business process can be executed by a Web service, since most business processes include activities performed by people. To bridge this gap, the BPEL4People whitepaper, developed by SAP and IBM, discusses extensions to BPEL that incorporate human interaction. BPEL4People has been submitted to the OASIS standards organization.

Service Definition Languages

Service Definition Languages define the interface to a service (see Figure 5).

They are a critical part of enterprise SOA, as they define how a service should be used in terms of the messages the service can receive and send. For example a very simple service could receive an "Order Request" message and return either an "Order Response" message if the order was processed successfully or an "Order Rejected" message if there were a problem.

Important Service Definition standards are:

  • SCA (Service Component Architecture).  As mentioned earlier in the discussion of component framework standards, SCA is a component architecture that supports defining component contracts including the services provided and consumed by the component.
  • The Web Services Definition Language (WSDL). This can be used when integrating a Web service into a composite application as well as at run time in order to bind a definition of a service to an actual instance of that service running on a server. WSDL describes a Web service in terms of the input and output messages, and the destinations (called ports) to which messages are sent.

Message Definition Languages

Messages contain the data that an enterprise service receives or sends. Typically they are defined using XML and more specifically XML Schema (see Foundation Standards). The resulting data is then placed inside a SOAP message envelope for transportation (see Messaging Standards.

But just as it is easier to read and understand "good English" as opposed to "bad English", it is possible to have both good and bad designs for messages. To solve this problem, message definition language standards have been developed that define "good practice". The leading standard for this purpose is the Core Components Technical Specification (CCTS) developed by UN/CEFACT - the division of the United Nations that developed EDIFACT, the international EDI standard. CCTS defines:

  • How to name individual fields in a message
  • How to aggregate those fields together, for example all the fields in an address
  • How to combine those aggregated fields into larger structures, e.g. how to create a business message such as an order
  • How to specialize or extend those messages to meet specific needs. For example how to adapt the content of an order to a particular industry or locale, e.g. invoices in Europe must contain VAT whereas in the US they must not.

SAP uses the CCTS methodology in the definition of all its enterprise services.

Layer 3: Business Semantics Standards - Cut Across Industry Borders

The definition languages described in the previous section are essential when defining the different components used by enterprise SOA. But precise definitions of the individual services, messages and processes themselves (see figure 6) are required for efficient and precise use of business information across different technologies, markets, industries, and locales.

For example, a purchase order can be correctly processed only if each field in the message is correctly understood in the proper context.

Business semantics standards provide the common understanding necessary to execute a business process, such as order-to-cash, which may include messages such as order, ship notice, goods receipt, invoice, and remittance.

Industry Specific Standards

SAP with its 30-year history in building business process applications, has provided significant leadership in the development of business semantic standards by supporting a large number of organizations that are defining the standards necessary for specific vertical industries or for cross-sector uses. These organizations typically include both industry and private-sector organizations seeking to establish a cooperative relationship with national, regional, and international standards organizations. Today SAP is actively engaged in over 130 vertical industry standards development organizations, as well as numerous customer-focus groups and Industry Value Networks (IVNs).

Cross-Industry Standards

If the same design requirements for a house are provided to a dozen architects, the result would probably have the same basic features: dining room, family room, bedrooms, bathrooms, etc., but each house would probably be significantly different. Accordingly, each house would be more expensive to build than a standardized design as the opportunities for reuse of components would be limited.

On the other hand if the architects, or one architect, agreed on a base design for each house but with features that would allow it to be extended to meet different specific needs, then there should be significantly lower costs and faster time-to-market.

The same problem applies to many industry-specific standards. Industry specific standards organizations have been following the same design requirements in that they are often solving the same business problem, e.g. order-to-cash, but because there has been no coordination, the results are vastly different. The resulting proliferation has become a serious obstacle to interoperability, particularly when crossing industry borders. As a result, integration efforts have become extraordinarily expensive across industries. Research by Gartner and AMR suggests that, on average, a typical IT organization spends 30% to 40% of its budget on integration alone.

SAP believes that the challenge of multiple different business semantic standards needs to be addressed if lower costs and improved interoperability between systems is to be realized. There is a need for convergence of methodologies and business semantics standards across the landscape of vertical industries.

Adoption of the UN/CEFACT CCTS specification, described under Message Definition Languages is the critical "methodology" part of the solution. A common way of defining and describing messages that can be extended to meet the needs of a specific vertical industry will make integration much easier.

To achieve this SAP is encouraging vertical industry standards organizations to adopt CCTS. The result is that organizations have the flexibility to design messages as required by their communities of interest but the output of the messages following CCTS has a much higher degree of conformity and hence it should make it easier to map between the messages designed by the different groups.

Once a common approach to message design exists, the next step is to develop common definitions for the messages themselves.

SAP is heavily involved in several different standards organizations to help make this happen:

  • UN/CEFACT. UN/CEFACT is a department of the United Nations. It is responsible for the international version of EDI called EDIFACT. UN/CEFACT developed the CCTS specification and, through its harmonization process, provides a mechanism by which different vertical industry standards organizations can agree on the common parts of their message definitions.
  • Open Applications Group Inc (OAGi). OAGi develop XML message and process definitions that span both business-to-business (B2B) and application-to-application (A2A) integration scenarios. OAGi implementations are typically in manufacturing with a particular emphasis in the North American automotive market, although this is extending to additional vertical industries. OAGi has developed a canonical integration model of the data needed to build messages for business which is very useful for A2A.
  • Object Management Group (OMG). Apart from being the primary creator of standards for model-driven systems (see earlier descriptions of MOF, XMI and JMI), OMG also consolidates message and process definitions in the banking and other industries.
  • ANSI Accredited Standards Committee (ASC) X12 (ANSI X12). ANSI X12 is responsible for creating cross-industry business standards using ANSI ASC X12 EDI and XML syntaxes. Its use is primarily limited to North America. Outside of the Americas, EDIFACT is more generally used. ANSI X12 covers several sectors: government, finance, transportation, supply chain, and insurance (both medical and hazard).
  • Enterprise Interoperability  Center (EIC). EIC profiles existing standards to support an end-to-end business process in a specific industry or across multiple industries. It differs from other cross-industry standards organizations because of its focus on defining common business processes using existing message definitions.

The final blog in the series ...

The final blog in this series will provide a description of "Common Standards" that cross both technology and business semantic standards.