Welcome!

Microservices Expo Authors: Liz McMillan, Todd Matters, Pat Romanski, Elizabeth White, Stefana Muller

Related Topics: Microservices Expo

Microservices Expo: Article

Why WSDL Is Not Yet Another Object IDL

Maintaining a loosely coupled service architecture

There has been much debate lately on what exactly WSDL's purpose is, and much of that debate has focused on whether WSDL is an interface definition language (IDL), or whether WSDL is better used to specify message-level contracts (without any associated operational semantics).

In this article we present an argument that dealing with WSDL as a message-level contract description language is the right way to go for building loosely coupled Web services.

Interfaces and Contracts
Before we delve into the specifics of how WSDL should be used, we need to understand the difference between a classic interface and a contract. By understanding the different problems that each solve we can begin to form a picture of when it is appropriate to use one or the other.

Let's start by briefly recalling exactly what is meant by an interface.

In an object-oriented view of the world, applications are composed from objects - entities that encapsulate state and have a well-defined, publicly visible interface. The interface describes the operations or methods that an object supports and that other objects can invoke. Each method represents an action that, when invoked, may or may not result in the state of the object being changed.

In this object-oriented world, we assume that a shared understanding of how the interfaces of the objects are described exists, that there is a common language for defining them; that's the Interface Definition Language, or IDL. An IDL provides us with a collection of primitive abstractions that we can use to define objects in terms of their interfaces but also with constructs that enable us to create new abstractions (sometimes called "classes" or "interfaces"). The collection of abstractions makes the type system, which is shared throughout our entire object-oriented application. In fact, the type system characterizes the application since more than one type system cannot coexist (e.g., the type system of CORBA, DCOM, Java RMI, etc.).

An abstraction defines the in-memory representation of an object. The interface of an object is the entry point to this in-memory representation. When building object-oriented systems, it is easier to reason about objects in terms of their interfaces since we only need to know how to access the objects and not their actual layout of the in-memory representation. Nevertheless, there is always a conceptual association between an interface and an in-memory representation of an object.

In a service-oriented view of the world functionality is exposed via services that are entities that can send and receive messages. Applications are thus composed by combining services that interact through message exchanges. To enable services to be interoperable, the format of those messages and the message exchange patterns that make the service-to-service interactions have to be agreed on in advance through a contract; thus we need a language with which to express such contracts - a Contract Definition Language, or CDL, as opposed to an IDL.

Unlike an interface, a contract is about the information on the wire and not about how the in-memory representations of objects are accessed. (Note: Throughout this article, we leave the details about the concrete binding of WSDL messages aside and assume that the XML infoset described by the abstract messages is honored by any underlying bindings.) Contracts allow systems to be built from components (services) that have well-defined boundaries (see "References" section) . These services can be developed and evolve independently since they do not share any abstractions. No single type system spans all the components. All that is agreed upon is the information that is exchanged and not how to access any in-memory representation of the objects.

In the Web services arena, a WSDL document is the contract that a service advertises to its potential consumers. Since it is written in XML and (potentially) uses XML Schema, there is no need for shared abstractions or interfaces of in-memory representations.

The big win for this approach is that in any given system we must decide only upon what information needs to go onto the wire. This is a considerably simpler logistical problem to solve than ensuring that all components of a distributed application are able to share a common type system and that all developers (who may well be working for different organizations) understand the operational semantics of the various types in that system. In short, this makes developing distributed applications, particularly those that span organizations, easier and thus cheaper and more robust.

Web Services Description Language
In WSDL 2.0, the wsdl:portType element has been renamed to wsdl:interface (this is true at the time of this writing as per the November 2003 draft of the WSDL specification). Although its name is suggestive, the wsdl:interface element should not be treated the same as a Java interface/class, a C++ class, or a C# interface/class. As we argued earlier, a WSDL document is a contract that describes message exchanges and not a description of an interface for an object.

While it is usually a mistake to do so, consumers of a WSDL document may choose to use it as if it were an IDL document. In fact, many of the current Web services development tools do just that by converting WSDL documents to classes with methods and presenting an object-oriented view of the world to developers.

The wsdl:interface element should be seen as a group of message exchanges in which a Web service is prepared to participate. It defines the set of interaction patterns that are part of the contract a Web service advertises and to which it adheres. The WSDL working group might well have chosen to name this element wsdl:interactions to better represent its purpose.

The wsdl:interface element may contain any number of wsdl:operation elements. (Note: Renaming the overloaded term wsdl: operation as wsdl:exchange while keeping its semantics was discussed by the WSDL working group, but ultimately rejected.)

Again, these should not be treated like the methods of a Java/C++/C# interface/ class although once again current tool support tends to treat them as such. Instead, a wsdl:operation represents the set of messages that are exchanged as part of one of the supported interactions. The alternative approaches are shown in Listing 1.

It is important to understand that a message exchange is described in terms of the information that is on the wire. A WSDL interface makes no assumption about any state changes or correlation between messages, nor does it make any assumptions about what processing occurs in the service's implementation during a message exchange. In that sense, a WSDL interface is far less tightly coupled to its implementing service than the interface of an object that is intimately bound with its instances.

Example
To illustrate these issues, we'll look at a simple library application built using both an object and a service-oriented approach. First, the IDL documents for very simple library and book objects are shown in Listing 2.

It is assumed that the in-memory representations of the Library and Book objects are accessed through the methods available. It does not matter whether objects are passed or returned by value or by reference. There is always the shared understanding on how these objects are represented in memory and how they can be accessed.

Irrespective of different platforms or programming languages that are used to build the system, it is always the case that there are objects that can be accessed through the defined interface. For example, when CORBA is used the CORBA type system abstracts the use of different implementation technologies. The CORBA type system defines the shared abstractions between all the components of the system we are building.

A Library Web service advertises the contract that it expects its consumers to honor. The contract in Listing 3 defines a possible interaction with the service and the formats of the two messages that make the exchange pattern. The contract only talks about the on-the-wire representation of a book and the ISBN. No information is given about the way in which the in-memory representation of the book and the ISBN are accessed. The Web service and its consumer share only the knowledge of XML and XML Schema and so their boundaries are respected. Moreover, when we decide to evolve the application, we don't necessarily have to break existing consumers.

Let's say we want to get the title from a Book object. In order to add this new feature to our application, we will have to change the IDL (see Listing 4) and recompile the entire application since a shared abstraction has changed. It will not be enough to compile only those parts of the system that use this functionality. The change in the shared abstraction may impact the in-memory representation of every Book object in the system.

Evolving the WSDL document, on the other hand, does not need to break existing consumers. That's due to the flexibility of XML Schema and the fact that we do not share abstractions (see Listing 5). While it's true that there will have to be engineering work to upgrade the service to support the notion of a book title, this does not break the application as a whole since no in-memory representations or references to such are being passed around - only conformant XML messages.

Conclusion
Like XML Schema that can be used as a document validation mechanism or a meta-level type system, WSDL is broad enough in its scope to be (ab)used as something akin to an object IDL or as a contract description language. While there are proponents of the former, the simplicity of the contract view of WSDL is compelling since it is a natural fit with the loosely coupled nature of Web services-based applications.

Though WSDL 2.0 may yet provide the features necessary to support both views, we advocate the use of WSDL as a means of describing message exchanges in which a Web service participates. We believe that this approach yields the most loosely coupled system architectures, which are more robust in the face of changing requirements than those systems that impose an object-like view of the world onto a service-oriented application.

References

  • Box, D. "Service-Oriented Architecture and Programming (SOAP)," - Parts 1 and 2, talks from the MSDN TV archive: msdntv/episodes/en/20030827SOAPDB, msdntv/episodes/en/20030902SOAPDB. 2003.
  • Box, D. PDC 2003. Talks on Indigo and Web services
  • More Stories By Jim Webber

    Dr. Jim Webber is a senior researcher from the University of Newcastle
    upon Tyne, currently working in the convergence of Web Services and Grid
    technologies at the University of Sydney, Australia. Jim was previously
    Web Services architect with Arjuna Technologies where he worked on Web
    Services transactioning technology, including being one of the original
    authors of the WS-CAF specification. Prior to Arjuna, Jim was the lead
    developer with Hewlett-Packard on the industry's first Web Services
    Transaction solution. Co-author of "Developing Enterprise Web Services -
    An Architect's Guide," Jim is an active speaker and author in the Web
    Services space. Jim's home on the web is http://jim.webber.name

    More Stories By Savas Parastatidis

    Dr. Savas Parastatidis is the chief software architect at the North-East Regional e-Science Center (NEReSC), Newcastle, UK. He is NEReSC's expert in Grid Computing technologies and standards. Previously, he co-led an R&D team at HP's middleware division that produced the world's first XML-based transactioning system and represented HP during the early stages of the OASIS BTP standardization effort.

    Comments (13) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Leo Golubovsky 09/01/04 12:01:04 PM EDT

    It was interesting to read the article and the postings on it. My comment is based on my experience using all of the mentioned technologies(CORBA, SOAP, ...) and messaging systems.
    I think the important point from architecture perspective is the difference between object oriented interface contract and service/message oriented contract. Author is right about trying to differentiate the two. The service oriented approach is significantly simpler to support and agree upon where BROADLY distributed boundaries are in place (multiple organizations, ...). The sooner the architects will understand the differences and advantages of one VS. the other the better of we are.
    Unfortunately, I think the article puts CORBA in a bad light and that caused some outcry here. CORBA is perfectly capable of providing service interfaces as well. I have constructed systems where CORBA was used as a service on the boudary to accept XML messages (in the same way as SOAP or messaging systems are used).
    What needs to be understood that implementation world is heavily object oriented and will stay that way for a while. CORBA provided a great technology to support that.
    The archicture mistake that people did was exposing the object world to the boundaries where services should have been exposed. CORBA provided facilities to do both.
    WSDL, on the other hand, has significant limitations on dealing with object oriented world (and that is OK by design). But it finally/hopefully will force many "not so competent" architects to differentiate between two approaches and maybe we will start using both in their appropriate places.

    I hope this article will make people think in this direction, instead of the technology bashing. When we begin to understand these architecture differences, we begin to understand that it is not the technology used that is important. It is how we (mis)use the technology.

    Leo Golubovsky
    Director
    [email protected]

    Gopi Bulusu 04/29/04 10:52:34 AM EDT

    I think the author is trying to differentiate between
    distributed object oriented and message oriented approaches. While there are differences, those are *not* brought out clearly in this article.

    The thing to remember is that from a technical point of
    view, object oriented approaches can do whatever can be
    done by service oriented approaches (in fact distributed
    computing evolved from RPCs to DCE to CORBA).

    From a political and ease of use point of view, people with expertise in scripting languages would find it easier to use SOAP/WSDL, at least in the beginning.

    For those confused -- think about basic operating system interface, it is service oriented (system calls like read/write) -- there really is nothing new about service oriented architectures.

    Wolfgang Maerz 04/29/04 03:57:52 AM EDT

    The article descibes a SOA based on messages and message exchanges driven by business processes and argues that SOAP/RPC based on internal interfaces (WSDL like IDL) does not fit to SOA. That is excactly how UN/CEFACT and OASIS ebXML (now ISO 15000 series) works since May 2001. So ebXML is the true SOA from the beginning and WS tries to chatch up. But ut the moment 90 % of WS is RPC within a typed system dictated by the tools.

    Do we make systems for tools or for true e-business applications?

    Don Box 04/21/04 02:19:32 AM EDT

    There are several points that haven't been made:

    1. Pre-OBV CORBA was as much of a message description language as WSDL is. Post-OBV corba was where things got screwed up. No one seems to mention this.

    2. XML Schema doesn''t buy you "loose coupling" anymore than IDL did. The fact that many schemas use xsd:any is the trick. Of course, last time I checked, there was something called CORBA::any as well.

    DB

    Mike Dickson 04/20/04 05:20:44 PM EDT

    What an interesting read. On the whole I agree with Michi, I see this whole argument of WSDL vs. IDL being made from a position of arguing over definitions of words; i.e. message vs. methods. The reality is, to an implementor they are the same thing. On the whole IDL is a concise mechanism to specify interface behaviour, wether those interfaces are to "services" or "objects". Anyone who has done an even remotely involved CORBA project quickly learns that lots of lightweight calls on method (or message) interfaces are expensive and should be avoided. With WS this is doubly so since the XML encoding adds overhead of its own.

    Michi is right on target regarding the real issues (IMO, as an implementer who has used both technologies). CORBA fundamentally lacked a firewall friendly, NAT friendly transport mechanism as well as encryption. Web Services tries to address some of that but in the process we get to regress to RPC calls and a rats nest of "standards" with no single group to resolve the differences. Sounds like an excuse for vendors to sell more middleware to me.

    Savas Parastatidis 04/17/04 07:19:32 AM EDT

    Ooops... sorry... my < michi > and < /michi > tags were removed from my post and, hence, some of Michi''s comments appear as mine. Apologies.

    Savas Parastatidis 04/17/04 07:15:25 AM EDT

    Dear Michi,

    Thank you very much for your comments. It?s obvious that you feel strongly about distributed object technologies.

    Please allow me to contribute my thoughts to this very interesting discussion.

    Huh? How is "defining the format of a message" different from "defining a marshaling format?" Or, to be more precise, if WSDL does *not* define a marshaling format, where exactly is the format defined then? There has to be something that tells the receiver what to make of an incoming message. For Web Services, that''''s WSDL, period.

    There is nothing that tells the receiver what to do with the message. It?s the other way around. The WSDL document of a service tells consumers of that service about the structure of the messages that can be exchanged and the message exchange patterns in which the service is prepared to engage. That?s the contract. WSDL does not describe the interface of an object as it is the case with an object IDL. A Web Service is not an object. If one wants to implement it as such, that?s up to the implementer.

    Through our article we wanted to illustrate the differences between the use of WSDL in Web Services and an object IDL in a distributed-object system. The object IDL describes a common abstraction that is shared throughout the system (for example, the Book class). The abstraction is defined in terms of its interface. Any change to the shared abstraction and all those components that use it will have to be made aware of the change (they will have to be recompiled, at least in most of the cases). There is also a coupling of the identity of those abstractions (the references), their state, and the interface providing access to that state. That?s an object. We build our distributed-object applications around the concept of an object with the above characteristics. Pass-by-reference is the common (but not the only) way of passing information around.

    In a distributed object world I can use an object IDL to describe a Book class, instances of which can exist anywhere on the network and I can pass references to them around. The reference also acts as the identity of the object and the coupling of identity and state with the object?s specific interface (described in IDL) is what characterise an object. Can we have services in this object-based world? Of course we can. That?s what CORBA services are all about.

    Of course we can twist the definitions around and say that an interface of an object describes the messages that instances of the described abstraction can accept. Also, one could say that the messages a Web Service accepts effectively define the interface of an object. To my mind, the former is the way in which the distributed-object world moves to service-orientation while the latter is the way in which the distributed-object concepts are applied using Web Services technologies.

    I am not sure about you but I personally see a difference between a service-oriented world and a distributed-object world. I see both as valid approaches to building systems and perhaps one makes more sense than the other in particular scenarios.

    We are not in a world where there is a single view of the distributed system, where there is single ownership of the distributed components of one single application that is scalable in a similar way the web has scaled. I have yet to see a distributed-object installation with the same characteristics but I see Web Services as an attempt to do just that (not necessarily one that it will succeed but at least we can try).

    Oh boy. What please is a description of the type and number of parameters for a remote invocation, if not the definition of a data type? In my computer science course, I was taught that a data type is a "definition of a range of values and the operations that can be performed on those values." When WSDL describes a message and the parameters that are legal for that message, what is it doing if not defining a data type?

    A message consists of information. A message does not accept parameters. In my computing science course I was taught that operations/methods/functions and not messages accepted parameters. A shared abstraction, a class, an interface is defined in terms of its methods/functions/operations and those are defined in terms of the parameters that they can accept. A message is a message; nothing more and nothing less.

    Just because WSDL 1.1 has the concept of a message part which is used by RPC people as the way to communicate parameter information, it doesn?t mean that we are describing operations of a shared abstraction. WSDL describes messages. I believe that the choice of names for the elements (?interface? and ?operation?) are not the right ones because they lead to confusion.

    Right. You have changed the definition of a data type and, surprise, surprise, all system components that use that data type are affected. So, what''''s new? Or how does that differ from WSDL? If I change a WSDL type, all system components that use that type have to change as well.

    You seem to have missed what we have suggested in our article. We suggested that the evolution is much easier. It?s much easier to change the XML Schema describing the valid messages without affecting existing consumers of the service while allowing new consumers to take advantage of the new functionality. In a distributed-object world a simple change like that would mean a complete recompile of the parts of the application that use the same shared abstraction.

    Now, that is interesting. So, I have a message that sends a single floating-point value from sender to receiver. Then I change the message to provide a string instead. The string contains the floating-point value as a string, in scientific notation, for example. And you are telling me that, due to the magic of WSDL, or XML, or whatever, there is no problem with that and that things will continue to work despite the fact that both the format of the message and it''''s semantics have changed? Please, don''''t make me laugh.

    I am glad we are amusing you.

    I don?t think anyone suggested that WSDL was responsible for describing the semantics of the information being exchanged. There are many clever people working on semantic languages, like RDF. Of course if the contract of a service evolves in a way that the previous incarnation breaks, then all bets are off. However, our argument was that it?s much easier to evolve the service contract without breaking existing applications.

    Right. It''''s not an object IDL because there are no objects in Web Services. Talk about throwing the baby out with the bath water. See

    http://groups.google.com/groups?q=had+to+work+with+author:Michi+author:H...

    Right! Many of your suggestions are about making Web Services like an object-based system (lifecycle management or soft-state management, coupling of identity with interface, etc.). See the WS-RF recommendation (http://www.globus.org/wsrf) as an example of your ideas already finding supporters. We have already disagreed with the approach that the WS-RF people have taken and, for the moment, it seems that Oracle, Sun, and Microsoft agree with us since they haven?t adopted it.

    The rest of your suggestions are really obvious to be honest... There is already work on transactions, security is an OASIS standard, we have stateful interactions in the form of contextualisation, we have notification specs, HTTP can traverse firewalls (at least those firewalls that don?t do application-level blocking), and we have the XML infoset that can be used for binary transfers. So, apart from the object-based stuff, the rest are pretty safe predictions, don?t you think?

    Thank you for your comments.

    Best regards,
    .savas.

    Jim Webber 04/17/04 06:36:56 AM EDT

    Hello Michi,

    WSDL defines a message format and a messge exchange pattern for a service. How values are marshalled into those messages is service-specific. This does not imply arbitrary data, just that the way in which marshalling and unmarshalling is done is not uniform across all services.

    On your second point, if you change the format of the message to something which isn''t compliant with the schema of the message, then it breaks - that is true. However the example in our article did not break the schema of the message since the schema was extensible.

    Loose coupling is enabled because there is no relies-on relationship between the implementation of the consumer or service implementation, only adherence to message contract.

    Finally I do not believe that the baby has been thrown out with the bathwater. But like your assertion that the baby gurgled down the plughole, it is an opinion not necesarily a fact.

    Michi Henning 04/16/04 05:22:47 PM EDT

    > This is inaccurate. WSDL does not define a marshalling
    > format, it defines the format of a message, and it is
    > silent on how that message might be constructed.

    Huh? How is "defining the format of a message" different from "defining a marshaling format?" Or, to be more precise, if WSDL does *not* define a marshaling format, where exactly is the format defined then? There has to be something that tells the receiver what to make of an incoming message. For Web Services, that''s WSDL, period.

    If what you say were true, then I could send arbitrary data to a web services endpoint and have it magically understood by the receiver. Or, to put it differently, what is the purpose of WSDL if not to provide a description of what constitutes a legal message, including the form in which that message is sent over the wire?

    > WSDL doesn''''t define datatypes since that is the
    > object-oriented way of doing things and Web Services
    > are not objects. WSDL defines only messages and
    > message exchange patterns.

    Oh boy. What please is a description of the type and number of parameters for a remote invocation, if not the definition of a data type? In my computer science course, I was taught that a data type is a "definition of a range of values and the operations that can be performed on those values." When WSDL describes a message and the parameters that are legal for that message, what is it doing if not defining a data type?

    > The fact of the matter is that a change in IDL means
    > that the application breaks unless everyone who has
    > a slice of it "signs off" on the changes.

    Right. You have changed the definition of a data type and, surprise, surprise, all system components that use that data type are affected. So, what''s new? Or how does that differ from WSDL? If I change a WSDL type, all system components that use that type have to change as well.

    > This is not necessarily so for WSDL as the article
    > points out because we can leverage XML schema to
    > define messages.

    Excuse me? "Leverage XML schema to define messages?" What is that supposed to mean? Are you, in all honesty suggesting that I can change a data type and magically have system components that use that data type know how it has changed? Wow. I didn''t know that web services, among all its other advantages, offered magic as well...

    > In two different Web Services implementations you can
    > have two different interpretations of a message (an
    > example of loose coupling), so your assertion that
    > "as soon as two types have different meaning in
    > different parts of the system, chaos ensues"
    > doesn''''t hold in this domain.

    Now, that is interesting. So, I have a message that sends a single floating-point value from sender to receiver. Then I change the message to provide a string instead. The string contains the floating-point value as a string, in scientific notation, for example. And you are telling me that, due to the magic of WSDL, or XML, or whatever, there is no problem with that and that things will continue to work despite the fact that both the format of the message and it''s semantics have changed? Please, don''t make me laugh.

    > Message-passing enables loose coupling and WSDL defines messages.

    I would like to hear a precise definition of this "loose coupling." This term has been bandied about for Web Services with complete abandon for a long time, and by people who don''t know how to distinguish between syntax and semantics.

    > Therefore I reassert that WSDL is not an object IDL.

    Right. It''s not an object IDL because there are no objects in Web Services. Talk about throwing the baby out with the bath water. See

    http://groups.google.com/groups?q=had+to+work+with+author:Michi+author:H...

    for more thoughts on the matter.

    Michi.

    Jim Webber 04/16/04 12:40:16 AM EDT

    Hello Michi,

    Thank you for your pointed critique.

    You said, "1) IDL defines types and operations that exchange instances of those types as parameters, thereby defining a marshaling format for messages. There is no difference between IDL and WSDL in this respect whatsoever."

    This is inaccurate. WSDL does not define a marshalling format, it defines the format of a message, and it is silent on how that message might be constructed.

    You also said, "2) IDL defines an API that allows a programmer to send and receive the messages that are defined. That API is standardized by CORBA, but there is nothing to state that this API must be used. For example, I could create a middleware that uses IDL and exchanges messages via IIOP, but has a completely different API (even an API that in no way is derived from the IDL -- the DII and DSI in CORBA are examples of such an API, but I can define others)."

    This is is true, but is certainly not the canonical use where we consider the application to be composed of a system of location transparent objects. You then go on to say, "A WSDL definition does precisely what IDL does: it defines a marshaling format for the data types that are described in the WSDL definition. As far as I know, there is currently no standardized API for how to use instances of types that are defined in WSDL."

    This is inaccruate too. WSDL doesn''t define datatypes since that is the object-oriented way of doing things and Web Services are not objects. WSDL defines only messages and message exchange patterns.

    The fact of the matter is that a change in IDL means that the application breaks unless everyone who has a slice of it "signs off" on the changes. This is not necessarily so for WSDL as the article points out because we can leverage XML schema to define messages.

    In two different Web Services implementations you can have two different interpretations of a message (an example of loose coupling), so your assertion that "as soon as two types have different meaning in different parts of the system, chaos ensues" doesn''t hold in this domain.

    Message-passing enables loose coupling and WSDL defines messages. Therefore I reassert that WSDL is not an object IDL.

    Michi Henning 04/15/04 11:02:45 PM EDT

    What nonsense. The authors obviously don''t know much about CORBA, nor have they thought clearly about the separation of type system, marshaling format, and API.

    First of all, the distinction between interfaces and contracts is inappropriate and arbitrary. An IDL definition does precisely two things:

    1) IDL defines types and operations that exchange instances of those types as parameters, thereby defining a marshaling format for messages. There is no difference between IDL and WSDL in this respect whatsoever.

    2) IDL defines an API that allows a programmer to send and receive the messages that are defined. That API is standardized by CORBA, but there is nothing to state that this API must be used. For example, I could create a middleware that uses IDL and exchanges messages via IIOP, but has a completely different API (even an API that in no way is derived from the IDL -- the DII and DSI in CORBA are examples of such an API, but I can define others).

    A WSDL definition does precisely what IDL does: it defines a marshaling format for the data types that are described in the WSDL definition. As far as I know, there is currently no standardized API for how to use instances of types that are defined in WSDL. As a result, each Web Services platform defines its own proprietary API. How this can be an advantage is beyond me -- this is going back to the old proprietary days of vendor-specific APIs. (One can argue that the CORBA-defined API is sub-optimal (and I''d be the first to agree), but to derive an inherent architectural difference between web services and CORBA based on this is simply in error.)

    To suggest that IDL defines a memory layout is ludicrous and shows a fundamental lack of understanding of CORBA. IDL does not define a memory layout in any way whatsoever. In fact, it also does not mandate that a CORBA object has to be implemented by a programming-language object. If I so choose, I can make a single programming-language object implement an arbitrary number of CORBA objects, or I can implement a single CORBA object as multiple different programming-language objects (for example, using servant locators), or I can implement my CORBA objects as lumps of data, using no programming-language objects at all.

    > It will not be enough to compile only those parts of the system that use this functionality. The change in the shared abstraction may impact the in-memory representation of every Book object in the system.

    What nonsense. The change in the abstraction affects precisely those parts of the system that use the functionality, and no others. Specifically, the change affects any compilation unit that includes the generated header file for the Book definition and that uses instances of a book. No other parts of the application are affected, and no other parts of the application must be recompiled. (Of course, if the authors insist on putting all IDL definitions into a single IDL source file and on including the generated header file in all programming-language source files, the entire application will indeed need to be recompiled. But only someone who is clueless would do that.)

    The example to show how to evolve the application to add an extra operation to the Book interface is flawed as well. For one, evolving an interface by simply adding an operation is simply illegal, period. That is true for both IDL and WSDL. In case of IDL, a receiver written to accept the original version will break if it receives a getTitle message, because that receiver does not understand the message. The same is true for WSDL: the original type definition does not have such a message so the receiver of a getTitle message will break just the same, because it also does not understand the message.

    Second, in both cases, the change modifies the meaning of an existing type, with no way to distinguish the old from the new type. Doing this is a fundamentally illegal operation in any type system: as soon as two types have different meaning in different parts of the system, chaos ensues.

    And, finally, the famous words "loosely coupled." I''d suggest search comp.object.corba for that term. It is a fallacy, whether we are talking CORBA, web services, or any other kind of type system. The authors need to attend a course in formal semantics before writing any more articles...

    Michi.

    Jim Webber 04/12/04 10:04:46 PM EDT

    Hi James,

    Would you mind ellaborating on the problems with this article? Perhaps Savas or I could rectify them for future work.

    Thanks.

    Jim

    James Greeve 04/05/04 05:41:52 PM EDT

    Very poor.

    @MicroservicesExpo Stories
    New competitors, disruptive technologies, and growing expectations are pushing every business to both adopt and deliver new digital services. This ‘Digital Transformation’ demands rapid delivery and continuous iteration of new competitive services via multiple channels, which in turn demands new service delivery techniques – including DevOps. In this power panel at @DevOpsSummit 20th Cloud Expo, moderated by DevOps Conference Co-Chair Andi Mann, panelists examined how DevOps helps to meet the de...
    For most organizations, the move to hybrid cloud is now a question of when, not if. Fully 82% of enterprises plan to have a hybrid cloud strategy this year, according to Infoholic Research. The worldwide hybrid cloud computing market is expected to grow about 34% annually over the next five years, reaching $241.13 billion by 2022. Companies are embracing hybrid cloud because of the many advantages it offers compared to relying on a single provider for all of their cloud needs. Hybrid offers bala...
    "When we talk about cloud without compromise what we're talking about is that when people think about 'I need the flexibility of the cloud' - it's the ability to create applications and run them in a cloud environment that's far more flexible,” explained Matthew Finnie, CTO of Interoute, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    @DevOpsSummit at Cloud Expo taking place Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center, Santa Clara, CA, is co-located with the 21st International Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is ...
    What's the role of an IT self-service portal when you get to continuous delivery and Infrastructure as Code? This general session showed how to create the continuous delivery culture and eight accelerators for leading the change. Don Demcsak is a DevOps and Cloud Native Modernization Principal for Dell EMC based out of New Jersey. He is a former, long time, Microsoft Most Valuable Professional, specializing in building and architecting Application Delivery Pipelines for hybrid legacy, and cloud ...
    Containers, microservices and DevOps are all the rage lately. You can read about how great they are and how they’ll change your life and the industry everywhere. So naturally when we started a new company and were deciding how to architect our app, we went with microservices, containers and DevOps. About now you’re expecting a story of how everything went so smoothly, we’re now pushing out code ten times a day, but the reality is quite different.
    There's a lot to gain from cloud computing, but success requires a thoughtful and enterprise focused approach. Cloud computing decouples data and information from the infrastructure on which it lies. A process that is a LOT more involved than dragging some folders from your desktop to a shared drive. Cloud computing as a mission transformation activity, not a technological one. As an organization moves from local information hosting to the cloud, one of the most important challenges is addressi...
    For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
    21st International Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy. Me...
    "We are a monitoring company. We work with Salesforce, BBC, and quite a few other big logos. We basically provide monitoring for them, structure for their cloud services and we fit into the DevOps world" explained David Gildeh, Co-founder and CEO of Outlyer, in this SYS-CON.tv interview at DevOps Summit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    Microservices are increasingly used in the development world as developers work to create larger, more complex applications that are better developed and managed as a combination of smaller services that work cohesively together for larger, application-wide functionality. Tools such as Service Fabric are rising to meet the need to think about and build apps using a piece-by-piece methodology that is, frankly, less mind-boggling than considering the whole of the application at once. Today, we'll ...
    Cloud Expo, Inc. has announced today that Andi Mann and Aruna Ravichandran have been named Co-Chairs of @DevOpsSummit at Cloud Expo Silicon Valley which will take place Oct. 31-Nov. 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. "DevOps is at the intersection of technology and business-optimizing tools, organizations and processes to bring measurable improvements in productivity and profitability," said Aruna Ravichandran, vice president, DevOps product and solutions marketing...
    In his session at Cloud Expo, Alan Winters, an entertainment executive/TV producer turned serial entrepreneur, presented a success story of an entrepreneur who has both suffered through and benefited from offshore development across multiple businesses: The smart choice, or how to select the right offshore development partner Warning signs, or how to minimize chances of making the wrong choice Collaboration, or how to establish the most effective work processes Budget control, or how to ma...
    SYS-CON Events announced today that CA Technologies has been named "Platinum Sponsor" of SYS-CON's 21st International Cloud Expo®, which will take place October 31-November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. CA Technologies helps customers succeed in a future where every business - from apparel to energy - is being rewritten by software. From planning to development to management to security, CA creates software that fuels transformation for companies in the applic...
    In the decade following his article, cloud computing further cemented Carr’s perspective. Compute, storage, and network resources have become simple utilities, available at the proverbial turn of the faucet. The value they provide is immense, but the cloud playing field is amazingly level. Carr’s quote above presaged the cloud to a T. Today, however, we’re in the digital era. Mark Andreesen’s ‘software is eating the world’ prognostication is coming to pass, as enterprises realize they must be...
    A common misconception about the cloud is that one size fits all. Companies expecting to run all of their operations using one cloud solution or service must realize that doing so is akin to forcing the totality of their business functionality into a straightjacket. Unlocking the full potential of the cloud means embracing the multi-cloud future where businesses use their own cloud, and/or clouds from different vendors, to support separate functions or product groups. There is no single cloud so...
    Both SaaS vendors and SaaS buyers are going “all-in” to hyperscale IaaS platforms such as AWS, which is disrupting the SaaS value proposition. Why should the enterprise SaaS consumer pay for the SaaS service if their data is resident in adjacent AWS S3 buckets? If both SaaS sellers and buyers are using the same cloud tools, automation and pay-per-transaction model offered by IaaS platforms, then why not host the “shrink-wrapped” software in the customers’ cloud? Further, serverless computing, cl...
    Hybrid IT is today’s reality, and while its implementation may seem daunting at times, more and more organizations are migrating to the cloud. In fact, according to SolarWinds 2017 IT Trends Index: Portrait of a Hybrid IT Organization 95 percent of organizations have migrated crucial applications to the cloud in the past year. As such, it’s in every IT professional’s best interest to know what to expect.
    The taxi industry never saw Uber coming. Startups are a threat to incumbents like never before, and a major enabler for startups is that they are instantly “cloud ready.” If innovation moves at the pace of IT, then your company is in trouble. Why? Because your data center will not keep up with frenetic pace AWS, Microsoft and Google are rolling out new capabilities. In his session at 20th Cloud Expo, Don Browning, VP of Cloud Architecture at Turner, posited that disruption is inevitable for comp...
    Companies have always been concerned that traditional enterprise software is slow and complex to install, often disrupting critical and time-sensitive operations during roll-out. With the growing need to integrate new digital technologies into the enterprise to transform business processes, this concern has become even more pressing. A 2016 Panorama Consulting Solutions study revealed that enterprise resource planning (ERP) projects took an average of 21 months to install, with 57 percent of th...