Development Model for Services

Today we are very happy to participate in the announcement of the Service Component Architecture (SCA).
I among many others have written on the subject of contract first development for services, and the importance of being able to design first and deploy later. SCA defines a programming and deployment model to directly address this requirement.
Our interest in this is related to the language independent nature of SCA (we provide Java and C++ implementations of our runtime), in the ability of our customers to obtain the “right” kind and size of infrastructure for SOA, and in the ability of tools to map easily and correctly to multiple SOA runtimes.
IONA has a unique, industry-leading microkernel-based, plugabble runtime specifically designed for SOA based on Web services. WSDL is the design metaphor we support, and through configuration changes we support WSDL mapping to multiple communication transport protocols and data formats.
We are developing an open source version, and leading a tools project at Eclipse. So we are very pleased to be part of SCA, since it’s annotation-based approach promises to help bridge the independent tooling and heterogenous runtime worlds.
Until now, other vendors have tended to focus on adapting existing runtimes, such as J2EE and EAI architectures, rather than developing new infrastructure from the ground up for SOA. Now this is changing, and the good news is that it is changing through industry cooperation.
I expect significant improvements for developers and SOA customers since SCA is aimed at making it easier to concentrate on the service definition rather than on the coding it often takes to map a service description to executable code.
To put this another way, I see a lot of criticism today of WSDL and Web services tools because they tend to be too tightly tied to existing object models and languages. SCA takes us in a better direction, providing designs, metadata, and configuration based deployment specifically for SOA infrastructure.

8 responses to “Development Model for Services

  1. Hey Eric,
    I would argue that WSDL is a flawed metaphor for supporting SOA since it’s unashamedly about rpc. While this simplifies matters for the range of programming technologies that one might want to support in a framework like SCA, it is ultimately harmful for integration at a business meaningful (workflow) level.
    So I’m worried that SCA is another WS-IF in waiting. Can you head off my worries?

  2. Jim,
    Given that the only business workflow language and execution environments with real traction, ie BPEL, is explicitly based on (abstract) WSDL, can you clarify why this is a problem?
    One of the reasons I like SCA so much is that it has a natural affinity for BPEL. I’m convinced that most useful business services with composite characteristics and/or high degrees of asynchrony will be based on BPEL in the coming years.
    One final point: the reality is that WSDL has mass adoption and isn’t going to go away any time soon. You can attack it or figure out how to take advantage of it. I’m opting for the latter.

  3. Hi Jim,
    I can’t say I agree that the WSDL spec is RPC oriented. It may be true that many of the tools that implement WSDL have chosen to focus on the RPC style, and not enough industry support has been given to the document oriented style, but WSDL does support both styles.
    In this sense SCA provides a helpful programming model because it makes it easier to develop and deploy loosely coupled, asynchronous Web services. The problem of the industry being oriented around the RPC style of Web services is exactly what SCA is designed to address.

  4. Torsten Winterberg

    Hi Jim,
    do you mean the Apache WSIF with your reference to WS-IF? Could you shortly explain, what’s the problem with that?

  5. Hi Eric, you mention that you see lot of criticism today of WSDL and Web services tools because they tend to be too tightly tied to existing object models and languages.
    With a sound architecture, it is really possible to decouple service implementations from service interfaces using current tools, object models and languages (maybe just by dropping that beautiful wizardry and thinking twice).
    I am more afraid of the SDO sister specification. The use of SDO could make the realization of object models in the application or module more difficult compared to POJO-based tools.
    At the end of the day, we might have more procedural style, transaction script like service implementations. I think that this is a good thing if the business logic in the service is thin but not if the business logic is heavy.
    What is your opinion?

  6. Hi Robin,
    Yes, I agree that “best practices” for service oriented development can be achieved using current tools. The problem is partly education since XML and Web services are something different than a Java or C# object, and now developers have to understand both instead of focusing on a single language or technology base.
    The problem is also partly that the tools make it easy to do the wrong thing – i.e. simply generating a Web service version of a Java or C# object.
    When using a “contract first” approach it may be necessary to fill in some code between the contract and the objects implementing the service to assemble or compose everything correctly. Here is where SCA comes into play, and promises to make life much easier.
    Regarding SDO I have to admit that I am not sure I understand your concern. Perhaps you could explain in a bit more detail?
    And finally, yes, I agree that thin services are in general better than thick ones, and that embedding too much business logic in the service creates maintenance issues. We have seen our SOA customers run into that exact problem in the past.
    This is the promise area of business process management of course, but for that to become real we will also need a good foundation of services.

  7. Eric,
    Is the intent that developers will work directly with SCA and then bind it to the appropriate transport? If so, how does it relate to contract first? That is, as a WS architect/developer, am I going to create WSDL, then generate SCA-based types and config info, or am I going to work in a SCA-based environment first and then generate WSDL?

  8. Hi Tim,
    SCA supports both approaches, at least in the specifications. The tooling for SCA is something that we are just starting to look at, especially focusing around the proposed SOA tooling project at Eclipse.
    But it is possible, for example, to create or import a WSDL file into the SCA environment and then through configuration and annotation metadata, stitch that WSDL interface up to a number of Java objects that implement the service.
    It is also possible to start with the Java objects and add annotation metadata sufficient to generate the XML artifacts needed to stitch things together.
    Our expectation, and perhaps this is why you will see me emphasize this, is that the tooling will support the contract first approach and allow developers to start with the WSDL.