Skip to Content

This is the final blog 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. The Delivering business value through a comprehensive standards-based approach to enterprise SOA – Part 2 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 3 provided 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, and “Business Semantics” which are actual definitions that are written using the language, e.g. English.

This Delivering business value through a comprehensive standards-based approach to enterprise SOA – Part 4 provides a description of “Common Standards” that cross both technology and business semantic standards and draws the series to an end with a conclusion.

Layer 4: Common Standards – Standards That Cross Multiple Layers

This section covers standards that are “common” as they are often used together with other standards or that cross more than one of the other three layers in the standards taxonomy (see Figure 7). They include: Profile, Management, Security, Policy, Ontology and Development standards.

image

Profile Standards

An individual technology standard is rarely used on its own. For example, security standards and reliable messaging standards are often used together for business integration to ensure that messages are delivered securely and reliably. But many technology standards offer a lot of choice because they are written with the idea that they could be used in many varied circumstances. If these standards, which each allow a lot of choice, are then used together, then the possible permutations of the way they can be used can rapidly become immense.

So the greater the choice, the harder it is to build solutions as decisions have to be made on what to do in each case when often the benefit of one choice over another is not very clear. This is particularly a problem when an enterprise service is running on a different system, as the implementer of the service on the other system may make different choices than the ones that a consumer of that service can or would make. Worse, the implementer of that service may be constrained in the choices they can make by the software on which their enterprise service runs. As a result, realizing a compatible set of options may be impossible.

So, in this situation “less is more”, i.e. the fewer choices that have to be made, then the easier the decisions become and the more likely they are to lead to a successful result.

Profile Standards fix this problem by identifying a set of one or more standards and then defining a “profile” of those standards that reduces the choice as well as provides specific guidance on how the standards should be used together.

Web Services Interoperability Organization (WS-I)

For Web services, on which enterprise services are built, the Web Services Interoperability organization (WS-I) is the leading standard setting organization. WS-I has developed, or are developing, several profiles:

  • WS-I Basic Profile – defines how the SOAP, WSDL and UDDI specifications should be used together
  • WS-I Basic Secure Profile – defines how the WS Security specification should be used to secure messages
  • WS-I Reliable Secure Profile – provides interoperability guidance for the joint usage of the WS-Reliable Messaging and WS-Secure Conversation standards to provide secure reliable delivery of messages. (This standard is still under development).

But WS-I doesn’t just develop profiles. The WS-I members also develop sample applications that are then used to test that solutions from multiple solution providers actually interoperate with one another in practice.

SAP is chair and board member of WS-I and chairs the Sample Applications Working Group that tests the interoperability of solutions developed by multiple solution providers.

Vertical Industry Standards Group “Profiles”

Vertical industry standards groups also frequently develop “implementation guides” that are really profiles that describe how messaging standards such as Web services, should be used with their business semantics standards, i.e. their business messages. As with business semantic standards, SAP’s goal is to reduce this proliferation by leveraging technology profiles, such as those developed by WS-I, and by developing guidelines on how they should be combined with business semantic standards.

Management Standards

Enterprise services, like any other resource, need to be managed through their complete life cycle (see Figure 8).

image

There is no single standard that can apply as the requirements vary significantly throughout their life. This leads to the need for several standards.

During requirements, design, build and deploy, standards are needed to manage the various components used to build and test an enterprise service. Key standards are:

  • Development Management – During requirements, design, build and deploy a comprehensive a standards-based integrated development environment is needed to manage the different versions of the components that exist. The “de facto” standard is the Eclipse open source development framework
  • Repository Management – This includes standards for the discovery of enterprise services and their changes during design, development and evolution – the Universal Description, Discovery and Integration (UDDI) is the key repository specification that applies. See also the standards on Metadata Infrastructure.

During deployment and operation of the enterprise service additional standards are needed:

  • Operational Management – This includes standards to manage the deployment and operation of enterprise services. Since enterprise services are built on top of Web services and/or Java, Web services management and related standards are important. These include:
    • Common Information Model (CIM)that describes the information about hardware and software resources that needs to be captured and monitored to manage systems
    • Java Management Extension (JMX)that specifies a management architecture, APIs and management services aimed at management of and through the Java programming language, and
    • Web Services Management (WS-Management) – provides a Web Services based API that allows access to CIM resources.
  • Identity/Resource Management – These are standards that are used to manage access to resources. The lead standards here are the Lightweight Directory Access Protocol (LDAP) as a directory of resources, and Service Provisioning Markup Language (SPML) that provides a framework for managing the provisioning and allocation of identity information and system resources within and between organizations – see also Security Standards.

Security Standards

Security standards are key enablers for achieving the security goals of service orientation. They address:

  • Message Integrity which ensures that a message received or sent by an enterprise service is not altered in transit
  • Authentication which allows the recipient of a message to verify who sent it
  • Confidentiality which ensures that the content of a message is kept private and can only be examined by the intended recipient, and
  • Identity Federation and Single Sign-On which provides management of “digital identities” that a person or system can use to enable seamless access to resources inside and outside the organization without the need to re-authenticate.

The Web Services Security (WS-Security) standard provides for message integrity and authentication by using “digital certificates” to digitally sign messages in the same way as a paper letter could be signed by an individual to prove authenticity. The same standards also use digital certificates to encrypt the key or code used to encrypt messages and therefore keep the content hidden from anyone not authorized to see it. X.509 developed within the International Telecommunications Union (ITU) is the critical standard for defining digital certificates.

Closely tied to authentication is “trust” which means that the enterprise service that receives a message can not only verify who sent it, but also trusts the sender and is therefore willing to process the message. It also works the other way round in that the sender of the message also trusts that the recipient of message will act on it when it is received. To do this the sender and receiver of a message rely on a common security infrastructure that offers central services such as brokerage of trust relationships and issuance of security credentials. Based on the well known core concept of the Public Key Infrastructure (PKI), new standards such as WS-Trust define the protocols for these services.

Trust is also the foundation that allows individuals to use the same “digital identity”, e.g. user name, password to sign on to networks of more than one system or enterprise in order to conduct transactions. Protocols such as Security Assertion Markup Language (SAML) and SPML define the conventions for management, propagation, mapping and transformation of these digital identities in highly dynamic, distributed SOA environments within the company or across trust domains between partners in a standardized manner.

Two other standards: SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are alternative methods of providing Message Integrity, Authentication and Confidentiality. They are different from WS-Security as they only secure the transport of the message and not the content of the message itself. Unlike WS-Security, SSL and TLS can’t be used to ensure that the messages weren’t tampered with before they were sent or after they were received.

Policy Standards

Before an enterprise service can be used information is needed on how to use it. For example, information is needed on whether the service requires messages to be digitally signed and encrypted for security purposes, and if so using which digital certificates. It is also often necessary to know if the messages must be sent reliably using WS-Reliable Messaging.

This type of information is known as a “policy” as it describes the implementation approach or policy that an implementer of an enterprise service has decided to adopt. Policy Standards provide a mechanism for defining them. They consist of three main parts:

  • Policy Standards that define how to describe any policy. In this case the critical standard is WS-Policy
  • Policy Attachments Standards which define how to associate or attach an instance of a policy to an object such as an enterprise service. Here the critical standard is WS Policy Attachments, and
  • Policy Assertions that define how to describe or assert the policies that apply in a particular case. For example how to define the security policies for an enterprise service or how to define the reliable messaging policies for an enterprise service. The critical standards are WS-Security Policy and WS-Reliable Messaging Policy Assertions.

Policy standards are used both at design time and run time. At design time they can be used to determine if the service can be used because the provider and consumer of the service have compatible policies, and at run time they can be used to control how messages are created and delivered, for example to determine which digital certificates to use to sign messages.

Ontology Standards

Clear, unambiguous definitions of the meanings and behaviors of messages, processes and services are essential.

Currently, vertical industry standards groups define business semantics of messages and services in plain text – relying on the reader to understand and interpret what the information means. As enterprise services become much more numerous, machine-readable semantic information about the services will be needed to make it easier to select and use enterprise services.

The Semantic Webstandards define two key languages for specifying semantics in a machine processible way:

  • Resource Description Framework (RDF) provides a formal way to define taxonomies of things, such as the roles involved in a supply chain  (buyer, seller, manufacturer, logistics provider, retailer, and so on), or a list of countries (USA, Germany, France, England, and so forth).  RDF also provides a formal means to make statements about things, such as that “BMW is located in Germany” or that “BMW is a manufacturer” or “Germany is a country.”
  • Web Ontology Language (OWL) extends RDF, providing additional means to formally express properties of and relationships among things.  An OWL-based set of information about things and their relationships is generally referred to as anontology.

Having precise, agreed-upon definitions of the properties of and relationships among things allows implementers and clients of an enterprise service to rely on a shared understanding of meaning.  Furthermore, if concepts such as “process purchase order”, “purchase order response”, “invoice,” and “returns” are based on taxonomies that are well understood, and statements about the elements of the taxonomies are constructed using formalized mechanisms such as those that RDF and OWL provide, then tools can help a person build a composite application by suggesting (not dictating!) what services to use.

For example, suppose a person creating a composite application has access to multiple enterprise services called “process purchase order.” Ontology languages can be used to record information about each service, to help distinguish among the services and to support a decision as to which one to use. For example one service could declare as part of its definition that “process purchase order returns purchase order response” whereas the other could say “process purchase order returns invoice“.  A human can read these definitions and make the inferences too, but when confronted with libraries of thousands of services and multiple, potentially complex statements about them, enabling software to help narrow down the choices is useful.

RDF and OWL have rigorous mathematical underpinnings.  Users of these languages need not understand these mathematics, but tools can use the underlying formal foundations to warn about inconsistencies within and among ontologies, which helps to debug a large mass of semantic information about complex service libraries.

The more widely that specific ontologies of business concepts are accepted, the closer we will get to exploiting the full potential of this kind of technology for formalizing semantics.  However, there are also strategies for federating separately-created ontologies. 

Ontology standards are still developing but hold significant promise in the future for automating the discovery and use of enterprise services.

Development Standards

Development Standards promote interoperability among development tools, by providing standard ways in which tools can work with each other and mechanisms for extending the base development environment to support new features.  Extensibility mechanisms define standard interfaces and protocols to which extensions must adhere in order to interoperate properly with the base development tool and with other extensions.

Two critical development standards are:

  • Eclipse, which, although typically considered an open source tool, has many of the characteristics of a standard because it specifies APIs, plug-in mechanisms, metadata schemas, and more
  • Unified Modeling Language (UML) and the related Meta Object Facility (MOF) and XML Metadata Interchange (XMI) standards (see Metadata Infrastructure standards)

Development standards are important to SAP NetWeaver Developer Studio, as it is built upon Eclipse and has a well-integrated UML modeling capability provided by an SAP partner.

Conclusion

Standards are the key enabler of enterprise SOA. Without standards the cost of designing, developing, deploying, operating and maintaining enterprise software will significantly increase and the value they deliver will be reduced.

Yet an approach to standards that focuses on technology standards and considers them merit badges, where mere compliance is the end goal, is inadequate. Technology standards are only really useful when combined with business semantics.

So how a software company approaches the adoption of standards in its solutions is critical. Only a company, such as SAP, that properly understands the importance of business semantic standards as well as technology standards, can provide solutions that maximize business value.

But just implementing a semantic or technology standard because it exists is not enough. To really deliver value, a fully comprehensive approach is needed that identifies the business benefit standards can deliver before implementing them in a platform, such as SAP’s Business Process Platform running on SAP NetWeaver 7.0, that delivers the reliability, scalability, performance and security a business needs.

Just as important is the approach to understanding, developing and evolving standards.

The SAP Standards Taxonomy (see Figure 9) provides a comprehensive framework that can be used to identify and understand standards in terms of their purpose and relationship to one another.

image

It consists of four main layers: Technology Standards that are designed to help computer systems work together; Languages for Defining Business Semantics, that are used to create formal standardized definitions of processes, services and messages; Business Semantic Standards, that are descriptions of individual “standard” processes, services and messages; and, Common Standards, that cross more than one layer.

Effective implementation and evolution of standards require that they are developed in a business context. SAP’s ecosystem provides this context for the SAP business process platform through initiatives such as: the Industry Titans initiative for engaging companies that create core infrastructure to improve the environment for enterprise computing; Industry Value Networks that engage business executives directly to understand the context and requirements of each industry; the Enterprise Services Community for defining in cooperation with businesses and independent software vendors semantically-compatible service definitions; and the Industry Standards group that takes service definitions and collaborates with external standards organizations to help make those definitions a standard while continuing SAP’s long-standing participation and leadership in standards bodies that develop technology and semantic standards.

By taking such a comprehensive approach to using and evolving standards for enterprise SOA, SAP is perhaps the only company delivering the enterprise SOA solution that will fully meet a company’s needs both now and in the future.

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