Payload constraints on the exchange of service information create two challenges for business-to-business (B2B) communications in a Service-Oriented Architecture (SOA) environment:

• Businesses need to impose unique constraints on this information even when they use vertical industry standards for exchange.
• Multiple constraint technologies typically are required to comprehensively declare the constraints, and to check information at run-time before it is dispatched to the actual service logic.

The Business Information Conformance Statement (BICS) is a simple specification that provides an extensible solution to both of these challenges. It has evolved from the original specification based on supportive feedback from vertical industry standards consortiums.

BICS 2: An updated specification

The Business Information Conformance Statement (BICS) 2 specification is an update and replacement to the earlier Business Integration -- Information Conformance Statement (BI-ICS) 1.0 specification, published by IBM at the beginning of 2004. (BICS 2 is also a simple rename from the original BI-ICS.)

BICS 2 is a simplification of the BI-ICS spec, so it's more powerful and easier to understand. The most significant changes from the earlier version are:

• It's more modular. The original single specification has been broken into multiple specifications.
• It's now an XML framework, built for today and the future with a set of published mechanisms for constraining information and extensibility for future constraint mechanisms on information. You can even define your own custom constraining mechanisms.

Back to top

Feedback from the industry

Throughout 2004 and 2005, various industry standards consortiums and their members provided feedback on the spec through presentations, tutorials, and discussions. I want to thank the members of XML.gov, MedBiquitous.org, Association for Cooperative Operations Research and Development (ACORD), Open Applications Group (OAGIS), and Organization for the Advancement of Structured Information Standards (OASIS) for providing helpful comments and suggestions. The simplification and the XML framework design in BICS 2 are largely a result of those discussions.

Back to top

Overview of BICS 2

For those not familiar with the earlier version, I will give a quick overview of what BICS is and what it does. Simply put, BICS is a constraint document -- meaning, an XML document that contains a set of information restrictions. From a computer science perspective, BICS uses two powerful tools: abstraction and indirection. A BICS document makes a statement, or declaration, about constraints on information.

The heart of the BICS framework specification is a constraint processing model. This model specifies the type of successful conditions that must take place across a set of constraints before the information being processed is considered conformant. A constraint mechanism can be an XML schema, a type system, or even some custom programming code. Within the core framework, BICS supplies an abstract InformationConstraintMechanismType which is subtyped to define concrete constraint mechanisms. Three concrete constraint mechanism specifications have been published along with the core BICS framework (see the BICS 2 summary page for links to these specs):

• W3C XML Schema Constraint Mechanism (WXSCM)
• Schematron Schema Constraint Mechanism (SSCM)
• MIME Constraint Mechanism (MCM)

BICS 2 is ready to accommodate any emerging constraint technology. You can also define other technologies as constraint mechanisms, such as schemas or type systems -- you can even define your own custom constraint solution. BICS instance documents contain a set of constraint structures, which are typed according to concrete constraint mechanisms. A BICS document can have constraints of varying types -- for example, multiple schemas and a Schematron assertion schema. An implementation for BICS can read a BICS document and apply the constraints to some piece of information to check conformance.

The framework's constraint processing model contains an indicator that specifies the type of successful processing conditions for the set of constraints within a BICS document. The processing model across constraints includes the sequential, any, and all conditions, each of which provides a different way to process the constraints.

One core value of BICS is its positioning to be deployed for constraint and validation checking of B2B information exchanged in an SOA, thus avoiding constraint checking in service logic.

It is important to note that the actual information being checked against a BICS document is out of scope. It can be in any format (such as text or binary), and can contain any type of information.

Back to top

Services typically require multiple constraint mechanisms

The pervasive use of W3C XML Schema's powerful information modeling capabilities within industry standards organizations naturally comes with limitations, such as the well-known inability to specify validation checks based on instance element values. These limitations underscore how important it is for businesses to use either an accompanying constraint technology that implements a comprehensive constraint checking approach on deployed services, or to use custom programming logic to help do so. A typical SOA scenario might be to use a W3C XML Schema validation followed by an XSL-based validation (such as Schematron assertions) prior to the business logic hand-off of the exchanged information in service. Multiple constraint mechanisms, including custom code, are often required to address limitations in any given mechanism. In addition, SOA information exchanges involve binary information, which can also be checked against a specific type system such as MIME.

Currently, there is no formal or standard way to declare this processing model to help automation. You can use a BICS document to declare this model for a service, as the BICS abstract InformationConstraintMechanismType provides consistent extension points to the constraint processing model for specific mechanisms like W3C XML Schema and Schematron. The BICS document snippet in Listing 1 specifies that an XML Schema and Schematron assertions must execute sequentially for the exchanged information being checked to be considered conformant to the service. A BICS document can reference a constraint that uses a URL (perhaps the location of a schema) as in this example. Constraints themselves can also be contained within the BICS document. See the BICS specification for details.

				
<InformationConformanceStatement> 
 <InformationConstraintProcessingModel
  modelType="sequence">
  <InformationConstraint
    xsi:type=
    "W3CXMLSchemaInformationConstraintMechanismType">
   <ProcessableConstraintURL>
   http://members.org/member.xsd
   </ProcessableConstraintURL>
     </InformationConstraint>
  <InformationConstraint
    xsi:type=
    "sch:SchematronInformationConstraintMechanismType">
   <ProcessableConstraintURL>
   http://Address.org/MyAddressLineSchematron.xml
   </ProcessableConstraintURL>
  </InformationConstraint>
 </InformationConstraintProcessingModel>
</InformationConformanceStatement>

Not only will any given constraining mechanism typically include limitations, but a single constraint technology is not the best choice for all information formats. Multiple constraining technologies are required for deployment into an SOA environment in order to provide a robust constraint declaration and runtime checking solution, since business partners can exchange any format of data. XML schemas are not applicable for use on the exchanged binary information. You can also use the BICS abstraction point of an InformationConstraintMechanismType with type systems (such as MIME) to declare that information be constrained by a binary data format type. For example, you can declare the processing model across multiple types of binary information. The BICS document snippet in Listing 2 specifies two different MIME image types within an any processing model -- indicating that either image format is acceptable information for a deployed service.

				
<InformationConformanceStatement> 
 <InformationConstraintProcessingModel
  modelType="any">
  <InformationConstraint 
    xsi:type="MIMEInformationConstraintMechanismType">
    <MIMEType>image/.jpg</MIMEType>  
  </InformationConstraint>
  <InformationConstraint 
     xsi:type="MIMEInformationConstraintMechanismType">
     <MIMEType>image/.gif</MIMEType>  
  </InformationConstraint>
 </InformationConstraintProcessingModel>
</InformationConformanceStatement>

Back to top

Businesses require specific constraints beyond vertical industry standards

Many industry-level XML standards are loosely defined -- which typically means that cardinalities are minimally defined. Ultimately, it makes sense to strive for tightly-constrained standards that help support higher levels of interoperability. However, in the vertical industry layers for standards, this remains difficult. Real-world business requirements often prohibit tight industry-specific standards with minimal flexibility, resulting in standards that cannot actually be used out-of-the-box by all stakeholders involved in real-world deployment.

This differs from infrastructure-level standards, which have less differentiating business value so businesses are more likely to embrace a common infrastructure. In contrast to industry-specific standards, infrastructure standards do not typically impede functions that might uniquely define a business's value. For this reason, it is difficult to obtain tight industry-specific standards that are specified by standards consortiums and can be used out-of-the-box by all businesses without customization; in contrast, comparable infrastructure-level standards are much easier to find.

While defining loosely-defined, or relaxed, standards in vertical industry groups is a pragmatic and arguably natural approach to vertical standards, it validates the need to formalize the ability to change (typically tightening) the constraints on B2B standards to meet requirements for a specific business. A formal language for doing this also facilitates advertisement of such profiled constraints for services, while at the same time permitting a business to maintain a unique value proposition. Currently, no formal, or standard, mechanism for doing this exists.

SOA includes a constraint design that facilitates changing information constraints as open standards are applied in higher processing layers toward business logic. A constraint document such as BICS provides a solution in this area, with the ability to formally declare an open industry standard schema as a first constraint, and also an additional business-specific schema constraint (or some other mechanism) as a changing constraint for a service. In this regard, BICS can be thought of as a formal service profiling language.

An important aspect of a dynamic SOA environment is that since BICS is an XML document, BICS-aware Web spiders and crawlers within an SOA environment can interrogate published BICS documents on Web pages or in registries, and determine support for specific industry standard schemas. This helps to facilitate dynamic B2B discovery. A BICS document can be interrogated to determine if a specific schema or other mechanism is declared as an information constraint.

Back to top

About the published concrete constraint mechanisms

As I mentioned, the core BICS framework provides the abstract InformationConstraintMechanismType, which must be subtyped to define concrete constraint mechanisms. W3C XML Schema, Schematron, and the MIME type system have published popular constraint mechanisms. The base abstract type defines several typical elements such as a name and description, as well as elements that support the location of a constraint if it is not contained within the BICS document. These elements are inherited into all concrete mechanism types, and provide consistency in BICS instance documents and automation processing.

Concrete constraint mechanisms can also provide extension constructs that make sense for specific types. As an example, the W3C XML Schema Constraint Mechanism specification provides the option to have a set of namespace-location pairs, which can be used to direct validation processing to use a schema at a specific location (URI) for a given namespace. This is particularly useful for specifying a second schema as a constraint which contains increased restrictions beyond a vertical industry standard -- essentially overriding any xsi:schemaLocation attributes present in an XML instance document being checked. A typical example might be that a specific business requires a certain field length to be imposed because a current database is already in place within the business. See the W3C XML Schema Constraint Mechanism specification for details.

You can also define your own constraint mechanism using the BICS framework.

Back to top

BICS proof of concept on IBM alphaWorks

IBM alphaWorks hosts Business Information Conformance Statements for Java (BICS4J), a proof-of-concept toolkit that supports the BICS 2 specification. Specifically, it includes a constraint engine that evaluates a given piece of information against a BICS document, and can be inserted into service invocation chains and handlers prior to the service business logic handoff. The implementation is written in Java code, and the constraint engine accepts inputs as file names, Java InputStreams, or Service Data Objects in the form of Eclipse EMF EObjects.

The alphaWorks implementation also supports Web services integration by providing an Apache Axis 2 message handler, which you can install in the Axis 2 request flow. To check conformance of contents in an incoming SOAP body against a deployed BICS document that's associated with the messaging-style Web service, the BICS Web services message handler executes the BICS constraint engine. See the BICS4J page on alphaWorks for details.

Back to top

Where will BICS go next?

Moving toward standards in this area is a prime motivation for BICS. Since the first version in early 2004, the technology has been discussed and presented in industry consortiums, and has received positive feedback and interest. BICS4J provides a proof-of-concept implementation of BICS 2 that integrates easily with Web services. The industry can benefit from a comprehensive constraint document such as BICS that's consistent with SOA in the following environments:

• Included as agreeable content in SOA agreements
• Referenced by interface definitions, as in Web services, to define comprehensive information constraints
• Advertised in SOA registries or on Web sites for publishing information constraints
• Used by infrastructure runtimes to provide conformance checking prior to handoff to upper-level service business logic
• Used to discover support for specific industry schemas by BICS-aware Web spiders and crawlers

Several potential directions exist for the BICS specification work. BICS might be submitted to a standards organization if enough committed supporters emerge. The potential for an open source implementation based on the BICS4J technology on IBM alphaWorks is, again, dependent on sufficient support. If you see a benefit in BICS becoming an industry standard, and want to help steer its direction, contact the author and get involved in its discussion group.

The BICS specifications, which include the popular constraint mechanisms, are available online -- see the links in Resources.

Resources

Learn

• Business Information Conformance Statement (BICS) 2 summary page: Check this page for the core BICS 2 framework as well as these three specifications:
  • W3C XML Schema Constraint Mechanism (WXSCM)
  • Schematron Schema Constraint Mechanism (SSCM)
  • MIME Constraint Mechanism (MCM)
  
  
• The developerWorks XML and SOA and Web services zones: Find out more about the technologies covered on in this article.
  
  
• Service Oriented Architecture (SOA) from IBM: Learn more about this flexible, robust infrastructure for modeling, assembling, deploying, and managing business processes for today's on demand business environment.
  
  

Get products and technologies

• Business Information Conformance Statements for Java (BICS4J): Download IBM's alphaWorks implementation.
  
  

Discuss

• BICS Forum: Discuss BICS and its direction.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• BICS 2: An updated specification
• Feedback from the industry
• Overview of BICS 2
• Services typically require multiple constraint mechanisms
• Businesses require specific constraints beyond vertical industry standards
• About the published concrete constraint mechanisms
• BICS proof of concept on IBM alphaWorks
• Where will BICS go next?
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into XML on developerWorks

Discover knowledge paths

Skill-building guides for XML, Linux, open source, cloud, Java, business analytics, and more.

Special offers