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:

• Implementation-first development
• 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 like the NetBeans Enterprise Pack 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. The nice thing to know about this is that NetBeans Enterprise Pack today provides all the tooling required for you to do contract-first development which is what we will explore in this blog entry. 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.


In this blog entry, I will demonstrate how to use the NetBeans Enterprise Pack and the Java EE Tools Bundle to create a Synchronous Request/Reply Echo system using the Contract-First development approach to service contract design. 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 using the built-in Test Driver Framework

1. Create the Provider’s Data Contract using XSD - Watch the video
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.

Explore the video above that shows you how to create an XML Schema from scratch.




2. Create the Provider’s Behavioral Contract using WSDL, adding a PartnerLinkType and Role - Watch the video
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.

Explore the video above that shows you how to create a WSDL contract from scratch.


3. Generate the EJB skeleton from the data and behavioral contracts and create the implementation - Watch the video
Once the service contract is established, generate the implementation skeleton using the NetBeans Enterprise Pack. Fill in the implementation details.

Explore the video above that shows you how to generate an EJB implementation skeleton from a WSDL.


4. Create the Client facing behavioral contract using WSDL, adding a PartnerLinkType and Role - Watch the video

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

Explore the video above that shows you how to create a client facing WSDL.

5. Create the BPEL Orchestration  - Watch the video 

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

Explore the video above that shows you how to create a BPEL orchestration.



6. Create the Composite Application and Deploy it  - Watch the video

Explore the video above that shows you how to create a Composite Application and deploy it onto the JBI Meta-Container on the Server.

7. Create unit and driver tests using the built-in Test Driver Framework - Watch the video

Explore the video above how to create test and driver tests.


Can't get easier than this - Watch the Videos online:

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 using the built-in Test Driver Framework

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?

• Watch the video here on how to use the XML Schema (XSD) Editor
• Watch the video here on how to use the WSDL Editor and the BPEL Visual Designer

The NetBeans Enterprise Pack 5.5 Early access that is part of the Java EE Tools Bundle is a FREE download that comes with a plethora of tooling that helps the SOA Developer. Tools like the XML Schema (XSD) Editor, the WSDL Editor, the BPEL Visual Designer, and all the other tools that are part of this download help the SOA developer be extremely productive at what he is doing.

Learn to use those tools here:

• Getting Started with XML Schema (XSD) tools
• Using the BPEL Visual Designer & the WSDL Edior tools

Download the Java EE 5 Tools Bundle Beta from http://java.sun.com/javaee/downloads/index.jsp for FREE, and provide us feedback on the improvements you'd like to see. It combines the new Java EE 5 SDK with NetBeans IDE 5.5 Beta, NetBeans Enterprise Pack 5.5 Early Access, and Sun Java System Application Server Platform Edition 9. This bundle also contains Project Open ESB Starter Kit Beta, Java EE 5 samples, Java BluePrints, and API docs (Javadoc).