Assembly Required

Some of the greatest advantages of SOA derive from adopting interface contracts. (Of course the benefit of interface contracts isn’t limited to SOA, but they are definitely applied to good advantage in an SOA environment).

By the way the definition of SOA that I use is that it’s a style of design, not a technology. The design is implemented using one or more technologies.

One of the crucial aspects of any SOA design is the contract between the service requester and the sevice provider, which is typically expressed (at least in part) using an interface definition language such as IDL and/or WSDL.

Among the many benefits of designing contracts and defining interfaces is the ability to divide up the work. Once the contract is in place (at a minimum this would be the definition of the data to be shared, often expressed using XML) separate teams can go off and work in parallel to develop the service provider and requester.

This approach can scale effectively as the library of reusable services grows, dividing up the work across multiple development teams, perhaps in different geographies. And this approach also creates the possibility that the work can be divided across companies, too. And that it could more easily be outsourced and/or offshored.

But with all the great potential for dividing up the labor involved in IT development comes an equally great responsibility to ensure that things go as planned when the divided up work gets assembled. Someone has to ensure that the interface definitions are interpreted and implemented consistently, and preferably before the whole application is deployed.

The folks at Business Management recently interviewed me about this. We have found, through sometimes painful experience, that it is best to validate individual interfaces as they are created rather than wait until final assembly. Many of our customers are starting to realize they need to change their approach to application assembly when using an SOA based approach.

Advertisements

2 responses to “Assembly Required

  1. Eric, I totally agree. Unfortunately WSDL got it a wee bit wrong… adding considerably to my SOA pain!
    Collocating the definition language and protocol bindings with deployment information makes life in the IT department a wee bit more complicated.
    In a nutshell its about service declaration vs definition in the C++ sense:
    Declaration and definition mean different things when they apply to a service, as opposed to when they apply to a contract. In the former case, a definition binds a name (i.e., a service instance, an object) to a physically invokable endpoint; whereas in the latter, a declaration merely binds a name to a logical service contract without allocating or declaring a physically invokable endpoint resource for it.
    The bit WSDL got wrong:

    <wsdl:service name=”FooService”>
    <wsdl:port name=”FooPort” binding=”tns:FooPortBinding”>
    <soap:addresslocation=”http://host:port/”/>
    </wsdl:port>
    </wsdl:service>

    Declaring that the service ‘FooService’ be made available using the SOAP protocol using ‘FooPortBinding’ be made available over the HTTP transport is fine.
    But unless your SOA is telepathic the host:port is probably wrong!
    What would have been better is a sort of ‘MIME type for services’ of the ilk binding/transport as follows:

    <wsdl:service name=”FooService”>
    <wsdl:port name=”FooPort” binding=”tns:FooPortBinding”>
    <requires endpoint=”soap/http” default=”http://host:port/”/>
    <supports endpoint=”soap/https” default=”https://host:port/”/>
    </wsdl:port>
    </wsdl:service>

    In this way we clearly define the deployment criteria but we stop short of allocating resources:

    We MUST support SOAP over HTTP for FooService over FooBinding.
    We MAY support SOAP over HTTP/TLS.
    You may be lucky with the default allocations. But they do not form part of the contract.

    This is one thing CORBA got right compared to more modern SOA technologies.
    Darach.

  2. Hi Eric
    I totally agree with you. Interface contracts are the core building block of an SOA. Contracts should be designed top-down and must cover enterprise needs like versioning, etc.
    In my opinion, you are not implementing a SOA if you are not designing the interface contracts top-down. If you don’t have well-defined contracts for your services of your IT, you won’t successfully adapt BPEL and BPM in the mid term.
    Very often, there are a huge number of interfaces within an IT landscape. Some are standard compliant (WSDL, IDL) some others not (Word document, excel sheets, etc). Mostly, the interfaces are managed within the application or the project itself. Other applications or project don’t know that system X does provide an interface already or this interface does not meet the requirements of this new integration need. There is a lack of overall governance.
    You would like to have an overview of the systems which are integrated with each other. Web Services Management seems to be the solution which gives you all that. Well, but the service contracts are still not well-defined and the system are integrated point-to-point. In this scenario, I think that web service management does not combat the cause of the mess it does only combat the symptom. Service contracts which are designed top-down are standard compliant, implementation agnostic and self-describing to some extent. This allows you to reduce the number of needed interface definition compared to point-to-point solutions. The IT is more agile to business demands because you don’t have to integrate the different systems from scratch again. If you want to reduce the number of interfaces in place, a strong governance for service contract design must be in place!
    I don’t say that web service management is not important. I say that well-designed service contracts are an indispensable precondition to have a successful SOA deployment in the mid-term of your IT.
    Darach, you’re right that WSDL covers some parts which shouldn’t be there. I’m sure that Eric means that the logical part of the WSDL is essential. The binding and service definitions are only relevant at deployment time. I think there are historical reasons why the physical information is in the WSDL as well. One is that web services are mostly correlated to SOAP over HTTP/S, so it’s simplest to put everything together. Second, where should a client get the endpoint address of a service? There was no WS-Addressing or UDDI in place at that time. The most pragmatic solution is to put it into the WSDL file. When I was talking about the service contract before, I was only talking about the logical part of the WSDL, not the binding and service definitions.
    An Artix developer can start developing without binding and service definitions. You manage the physical part of your WSDL and much more through policies within the Artix repository at deployment time. Your service implementation is transport/binding agnostic even you provide a SOAP/HTTP, SOAP/JMS or a CORBA endpoint. These are policies which are applied at deployment time and shouldn’t be placed in a static WSDL file.
    Oliver

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s