Skip to Content

Contents

  • In My Last Blog
  • A Metadata Rich Environment
  •       Semantically Rich Service Contracts
  •       The Benefits of Machine-Readable Service Contracts
  •       Quality-of-Service Constraints
  •       Configuration Invariants
  •       Version Metadata
  •       Metadata Management
  • Building the Right Components with Product Line Practices
  • Conclusion
  • Notes
  • References

In My Last Blog

In my last blog, Scaling the Business Process Platform Up: The Challenges, I recapped the concept of a business process platform, and described three significant challenges that we face in scaling the business process platform up:

  • Finding the right components
  • Building the right components
  • Configuration Management

In this blog, I outline some strategies for meeting these challenges.

A Metadata-Rich Environment

In order to make finding and managing large numbers of components tractable, a business process platform has to be a metadata-rich environment. Metadata provides machine-readable information about the components of the business process platform.

This section outlines the most crucial, foundational kinds of metadata that business process platforms need.

Semantically Rich Service Contracts

The contract of a service is composed of four fundamental elements:

  • Signature: The signature of a service defines the types of information that the service requires as input and the types that it produces as output.
  • Preconditions: A precondition is a constraint that must be satisfied in order for the service to execute in a well-defined manner. An example of a precondition for a service that transfers money from one bank account to another might be that the source and destination accounts have to be owned by the same customer. Some services might not have this restriction, but, for those that do, this precondition is an important part of the service’s contract.
  • Postconditions (Effects): A postcondition is a constraint that must be satisfied when the service has completed execution. Postconditions describe the effects that result from executing the service. For example, a postcondition of our example money transfer service is that the balance of the source account is decremented by the amount of the transfer, and the balance of the destination account is incremented by the same amount.
  • Information Invariants: Information invariants are constraints that apply to the information structures that services use as their input and output parameters. For example, an ordinary checking account may have an invariant that says that the balance of the account may never dip below zero. That invariant would invalidate an attempt to transfer an amount from an account that is greater than the account’s balance. However, a different kind of checking account with overdraft protection might have an invariant that states the balance may dip as low as negative one thousand dollars, but no more.

Typically in the industry today, the only part of the service contract that is expressed in a machine-readable fashion is the signature. For example, WSDL allows you to define the inputs and outputs of services. The use of preconditions, postconditions, and information invariants to define a service’s contract is the heart of an approach called Design by Contract™, which defines the semantics (the meaning) of the contract. When we express these semantics using formal constraint languages, they become machine-readable too.1

All too often, the semantics of a service contract are buried in code, and are not even captured informally in English or some other human language. In a metadata-rich environment, the full contract in machine-readable form – including the signature and the semantics – is an integral part of the component’s manifest.

Figures 1 and 2 illustrate how to declare a machine-readable contract for a money transfer service using UML®’s Object Constraint Language (OCL). The constraints are in the blue boxes (shaded boxes, if viewing in black and white).2 The UN/CEFACT Modeling Methodology is one example of a methodology that uses UML this way.3

image
Figure 1: Business Information Model

Figure 2’s business model leverages Figure 1’s information model by using the information classes as the types of service’s parameters.

image
Figure 2: Business Service Model

There are other avenues besides UML, including various initiatives under the banner Semantic Web Services aiming to use constraint languages in concert with the Web Services Description Language (WSDL) and in conjunction with the Semantic Web languages RDF and OWL. Sometimes these initiatives refer to constraint languages as rules languages, but the idea is the same. There are also emerging technologies for representing machine-readable constraints in a human language – such as carefully structured English – so that business analysts who are not technically oriented can read them.4

There are also approaches to structuring business information that reduce – but do not eliminate – the need to express information invariants in general constraint languages. UN/CEFACT has an approach called Core Components for organizing the definitions of global data types, such that the very structure of the definition of a data element provides a map of the element’s semantics.5 CCTS leverages ISO 11179-5’s approach to using semantic structure to drive the naming of data elements.6 ISO 11179-5 is also popular in the Semantic Web community. These semantic maps are powerful metadata that enrich the semantic content of the service contract when the data elements appear as parameters of services. We are just beginning to learn how to exploit this kind of metadata.

The Benefits of Machine Readable Service Contracts

Including service contracts in the metadata for the business process platform provides some basic benefits that are a foundation for addressing some of the scalability issues that I outlined earlier. Advantages include:

  • A precise, unambiguous contract: Most basically, a precise specification of the contract makes it more likely that the person who wishes to reuse the service component will understand whether the component is likely to satisfy the requirements. Mathematically specified constraints are unambiguous. This is particularly important in an age where value-chain driven business means that components have to interact with each other across organizational boundaries and across human language barriers. Whether the service user wishes to create a more powerful service, create an executable business process that invokes the service, or build some kind of specialized application with the service, knowing the contract helps.
  • Constraint enforcement: With some limitations7, tools can enforce constraints. For example, it is possible to generate code that checks whether a precondition is satisfied before invoking a service.
  • Collision detection: Breakthroughs in the field of knowledge representation make it possible to detect certain kinds of conflicts among contracts. Tools can prevent subtle bugs before they happen by warning a developer that the components she wishes to combine have mutually contradictory constraints. For example, a constraint on one component may require that the customer’s age be 18 or less, whereas a constraint on another component may require that the customer’s age be 21 or more. In order to take full advantage of these emerging tools, the languages used to define the information structures must be grounded via mathematical formalisms, as is the case with the Semantic Web’s RDF and OWL. Even with such formal grounding, certain kinds of collisions cannot be detected with certainty; but in such cases the tool can raise a warning flag, allow the human to decide how to proceed, and store the human’s decision. The next time a human encounters the same warning, the tool can display how other humans have decided to proceed in the same circumstance, and the tool can eventually learn from those decisions to suggest a default decision.
  • Semi-automating service composition: Tools are emerging that partially automate the identification of candidate services that may satisfy a requirement. The tools require the searcher to express the requirement in a machine-readable fashion, and they scan available services by matching the requirements against the service contracts. For the foreseeable future, the human will have to be the ultimate arbiter of whether to use the candidate services, which is why I label this approach as semi-automated. Once again, these tools require the use of formally grounded languages.
Quality-of-Service Constraints

Note that the service contracts I’ve talked about so far specify the functional behavior of the service. They do not specify non-functional, quality-of-service constraints. Yet quality-of-service constraints are important metadata too. Finding a suitable service is not just about finding a service that implements the functional behavior that you need. It is also about finding a service that satisfies your quality-of-service requirements.

It is useful to separate the functional aspects of the contract from the non-functional, quality-of-service aspects. For example, standards bodies might want to codify the functional behavior contract for a common service, such as a post to ledger service, while leaving the specification of quality-of-service constraints to negotiations among the providers and clients of the service. Implementers who provide the service can advertise the quality-of-service that the implementation offers.

Configuration Invariants

A configuration invariant is a special kind of information invariant that specifies a constraint having to do with a component’s design-time or deployment-time configuration parameters. The value of one configuration parameter may constrain the values of others. Tools can enforce these kinds of constraints, with some limitations. They can also detect collisions among configuration constraints that would result from specific combinations of components; again, sometimes detection is certain and sometimes only suspected.

Applying these principles of Design by Contract to configuration management does not solve all problems, but can help manage them.8

Version Metadata

You need quite a bit of metadata to get the versioning problem under control. Simply tracking the versions of the application is not enough. You have to track the versions of all of the application’s components, and you have to do that for each version of the application.

In order to be able to anticipate the potential ramifications of a change to a component, you also need a cross reference that keeps track of which applications are using which components, down to the version level. This, of course, impacts quality assurance procedures as well.

Metadata Management

As you can see, business process platforms need all sorts of metadata to reach their potential. Because of the wide variety of metadata, there is a danger that we won’t be able to use it in an integrated fashion. Too often, enterprises have quite a bit of metadata, but most of it is locked up in silos because each kind of metadata is managed by different tools that use completely different metadata management mechanisms.

That’s why I’ve been such a strong proponent of integrated metadata management technologies such as the Meta Object Facility (MOF™), one of the core MDA standards. The Eclipse Modeling Framework (EMF) is essentially a flavor of MOF that underpins Eclipse’s metadata management facilities. Eclipse’s tremendous traction holds out hope that the silos will start to break down. EMF is one of the most popular Eclipse downloads.

Building the Right Components via Product Line Practices

The Carnegie Mellon Software Engineering Institute (SEI) – the same organization that gave us the Capability Maturity Model (CMM) – has defined an approach to organizing for reuse called Software Product Lines (SPL). SPL addresses one of the main problems that has bedeviled component-based development – the problem of scope. Thoughtfully constraining the scope to which frameworks of components apply makes the problem of making the components truly reusable more tractable.

SEI defines a software product line (SPL) as “a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.”9 An example of an SPL is a set of products that manages risk for portfolios of tradable financial derivatives. Another example of an SPL is a set of role-based access security products. Note that the scope of these sample product lines is fairly narrow. It is easier to assure reusability over a well-defined, restricted scope than it is to do so over an ill-defined and broad scope.

The SPL approach (see Figure 3) divides the software development process into two distinct but related processes – core asset development and product development. Core asset development produces a framework of reusable assets for the product line, and defines an architecture for the framework. Product development uses the framework to produce individual products. A production plan provides instructions on how to use the framework in accordance with the architecture in order to produce products. It is interesting to note that SPLs are a cornerstone of Microsoft’s Software Factories approach to model-driven systems.

image
Figure 3: Software Product Lines10

Organizing a business process platform as a set of distinct but integrated product lines (see Figure 4), each with a well-defined scope, can help to make the task of building reusable service and process components more manageable.

image
Figure 4: Applying Software Product Lines to Business Process Platforms

Conclusion

Business Process Platforms will change the face of IT and business. For many reasons, the change will be gradual. Along the way we have to address some challenges that arise as we increase the scale of this new kind of platform. Now is the time to recognize these challenges and face them square on. An approach that combines this kind of pragmatism without losing sight of the ultimate goal can help ensure that business process platforms provide real business value at every stage of the evolution.

Footnotes

  1. For the technically inclined: Design by Contract requires that we express each precondition, postcondition, and invariant as a declarative, Boolean assertion.
  2. In OCL, each invariant is labeled “inv:” and In OCL, each precondition is labeled “pre:” and each postcondition is labeled “post:”. Comments are preceded by a double hyphen; I use comments to express the constraints in English.
  3. [UMM]
  4. [SBVR]
  5. [CCTS]
  6. [ISO 11179-5]
  7. For the technical reader: The limitations I’ve referred to several times have to do with the complexity of the constraints. It’s possible for tools to detect – with certainty – collisions among the relatively simple kinds of constraints that make up description logics. However, certainty is generally unattainable when trying to detect collisions among constraints that use first order logic.
  8. See [CZAR-KIM] – particularly sections 5 and 6 – for an interesting discussion of how tools can use invariants to manage configuration. The lead author is currently an academic, but spent many years in industry.
  9. [SPL]
  10. The “Sims Water Line,” depicted in Figure 4 and invented by Oliver Sims, uses the analogy of a water line to describe the separation of concerns between aspects of a system that surface to the application developer’s viewpoint, as opposed to aspects that the infrastructure handles below the surface. 

    References

    [CCTS] UN/CEFACT, Core Components, http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf , also published as ISO 15000-5 under the auspices of ISO TC 154

    [CZAR-KIM] Krzysztof Czarnecki and Chang Hwan Peter Kim, “Cardinality-Based Feature Modeling and Constraints: A Progress Report,” Proceedings of the First International Conference on Software Factories, OOPSLA 2005.

    [ISO 11179-5] ISO 11179 Metadata Registries, Part 5 Naming and Identification Principles, http://metadata-standards.org/11179/#11179-5

    [SPL] Carnegie-Mellon Software Engineering Institute, Software Product Lines, http://www.sei.cmu.edu/productlines/index.html

    [SBVR] Semantics of Business Vocabulary and Business Rules, OMG document bei/2005-08-01, 22 August 2005.

    [UMM] UN/CEFACT Modeling Methodology, http://www.unece.org/cefact/umm/umm_index.htm

    “Design by Contract” is a trademark of Interactive Software Engineering.
    “MOF” is a trademark of the Object Management Group.
    “UML” is a registered trademark of the Object Management Group.

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