SOA Blueprints-Contract-First Development

18 Aug 2007

SOA-Blueprints

One of the most important reasons for the fast adoption of the Service Oriented Architecture approach to building applications is because it allows enterprises to expose silo applications and data islands as reusable services that can then be orchestrated together into new re-useable business applications more easily. The real value of these services to any business is directly proportional to how easy it is to consume their services.

The Provider Service Description Contract in WSDL

The provider’s service description defined using the Web Services Description Language (WSDL) guarantees the contract between the Service Provider and its Service Consumers. This service description contract shields the consumer from the implementation details, the implementation framework, and the implementation language used to implement the provider. While the data contract is expressed using XML Schema Definition (XSD), the behavioral contract, the sequencing, the message exchange patterns, the transport bindings, the interfaces, policies, and other contracts are defined using WSDL.

The only dependency between the service consumer to the provider is the data contract provided using XSD and the behavioral contract provided using WSDL which in turn interoperate to produce the correct data mapping to the wire-protocol. Similarly, like the CORBA IDL, XSD and WSDL map nicely to multiple languages, thus allowing service providers and consumers implemented using different programming languages, and residing on multiple heterogeneous operating systems to interoperate.

Designing the Service Contract

Since the service provider and the service consumer may be implemented using multiple different languages, frameworks, and platforms, the only contract language that they all understand are XSD and WSDL. Since the only binding between the provider and consumer is the service contract defined in XSD and WSDL, it becomes extremely important to define this contract properly. There are currently two ways to design the service contract. They are:

1. Implementation-first development
2. Contract-first development

Implementation-First Development

In this approach you start coding the provider methods just because programmers are fond of writing a lot of code. The intention is that once the code is there, a tool can generate WSDL and XSD from the implemented classes. One thing that programmers should keep in mind is to ensure programming language specific styles, idioms and implementation details dont unintentionally creep into the service contract. This will make it extremely difficult for the consumer of your service especially if the consumer is being implemented using a different programming language than the provider.

Contract-First Development

Another way to do this is contract-first development where you are explicitly deliberate in the service contract design by creating the data contract in XSD and the behavioral contract in WSDL upfront. This approach forces the designer to focus on messages and contracts as the key concepts in designing a service contract. The way contract-first development works is as follows and is documented in the figure below.

The steps are as follows and are explained in more detail later:

1. Create the Provider’s Data Contract using XSD
2. Create the Provider’s Behavioral Contract using WSDL, adding a PartnerLinkType and Role
3. Generate the EJB skeleton from the data and behavioral contracts and create the implementation
4. Create the Client facing behavioral contract using WSDL, adding a PartnerLinkType and Role
5. Create the BPEL Orchestration
6. Create the Composite Application and Deploy it
7. Create unit and driver tests

Create the Provider’s Data Contract using XSD

The Data Contract is always defined using XML Schema. Data expressed in XML Schema is more descriptive since data types defined in Java or C++ are described only in code and are not shared with the client. To get decent reuse of XML Schema, you will need to remove any inline schema types from the WSDL document and store them separately. This allows the definition of type to be shared between development groups and these types will need to be used by many different developers.

Create the Provider’s Behavioral Contract using WSDL, adding a PartnerLinkType and Role

The behavioral contract, the sequencing, the message exchange patterns, the transport bindings, the interfaces, policies, and other contracts are defined using WSDL. A Contract-first approach to development makes following standards easier because all of the standards are written for the WSDL description. You can read about partnerLinkType and role from here.

Generate the EJB skeleton from the data and behavioral contracts and create the implementation

Once the service contract is established, generate the implementation skeleton using the tool of your choice and fill in the implementation details.

Create the Client facing behavioral contract using WSDL, adding a PartnerLinkType and Role

Create the client facing WSDL. You can read about partnerLinkType and role from here.

Create the BPEL Orchestration

Now that you have all the web-service descriptions, create an orchestration in BPEL.

Create the Composite Application and Deploy it

Create the Composite Application and Deploy it

Create unit and driver tests

Create unit and driver tests

Soap Box

The CORBA Interface Definition Language

A CORBA system is self-describing. In CORBA, contractual interfaces and boundaries with service consumers are specified using the CORBA Interface Definition Language (IDL) contracts and are purely declarative which means no implementation details are provided. IDL-specified methods can be written in and invoked from any language that provides CORBA bindings like Java, C, C++, Smalltalk, Objective C, COBOL, Ada, etc. The CORBA IDL provides operating system and programming language independent interfaces to all the services and components that communicate using the CORBA Object Request Broker (ORB) thus allowing service providers and consumers written in different programming languages, and residing on multiple heterogeneous operating systems to interoperate.

IDL allows component providers to specify the interface and the structure of the objects they provide in a standard definition language. This IDL-defined contract binds the distributed object service providers to their consumers. For one consumer to request something from a provider, it should know the target objects interface. The CORBA Interface Repository contains the definition of the interfaces with the metadata that allows components to discover each other dynamically at runtime.

The different distributed services provided by the CORBA ORB vendor determine the objects on the network, the methods that they provided, and the object interface adaptors that are supported. The actual location of the provider is transparent to the client. It should not matter one bit to the client whether the provider object is in the same process or half way across the globe.

This allows for the components to evolve independently without affecting other parts of the architecture. The interface-based model shields the consumer completely from the individual implementation details of the provider component and makes it possible to distribute the provider component to different contexts without changing the consumer’s programming model. Since the only dependency the consumer has to the provider implementation is the binding to the interface definition, it allows the provider component to be updated with bug fixes and improvements as long as the interface does not change.

For those of you who have been following my writings for more than a decade now, know that I could go on and on about the beauty of CORBA and its distributed component-oriented model.

Does all that I said above sound familiar?