Welcome!

Microservices Expo Authors: Elizabeth White, Pat Romanski, Liz McMillan, Yeshim Deniz, Carmen Gonzalez

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
    The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
    By now, every company in the world is on the lookout for the digital disruption that will threaten their existence. In study after study, executives believe that technology has either already disrupted their industry, is in the process of disrupting it or will disrupt it in the near future. As a result, every organization is taking steps to prepare for or mitigate unforeseen disruptions. Yet in almost every industry, the disruption trend continues unabated.
    SYS-CON Events announced today that HTBase will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. HTBase (Gartner 2016 Cool Vendor) delivers a Composable IT infrastructure solution architected for agility and increased efficiency. It turns compute, storage, and fabric into fluid pools of resources that are easily composed and re-composed to meet each application’s needs. With HTBase, companies can quickly prov...
    Building custom add-ons does not need to be limited to the ideas you see on a marketplace. In his session at 20th Cloud Expo, Sukhbir Dhillon, CEO and founder of Addteq, will go over some adventures they faced in developing integrations using Atlassian SDK and other technologies/platforms and how it has enabled development teams to experiment with newer paradigms like Serverless and newer features of Atlassian SDKs. In this presentation, you will be taken on a journey of Add-On and Integration ...
    Culture is the most important ingredient of DevOps. The challenge for most organizations is defining and communicating a vision of beneficial DevOps culture for their organizations, and then facilitating the changes needed to achieve that. Often this comes down to an ability to provide true leadership. As a CIO, are your direct reports IT managers or are they IT leaders? The hard truth is that many IT managers have risen through the ranks based on their technical skills, not their leadership abi...
    The essence of cloud computing is that all consumable IT resources are delivered as services. In his session at 15th Cloud Expo, Yung Chou, Technology Evangelist at Microsoft, demonstrated the concepts and implementations of two important cloud computing deliveries: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). He discussed from business and technical viewpoints what exactly they are, why we care, how they are different and in what ways, and the strategies for IT to transi...
    Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
    All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm.
    As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and micro services. While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your contain...
    As organizations realize the scope of the Internet of Things, gaining key insights from Big Data, through the use of advanced analytics, becomes crucial. However, IoT also creates the need for petabyte scale storage of data from millions of devices. A new type of Storage is required which seamlessly integrates robust data analytics with massive scale. These storage systems will act as “smart systems” provide in-place analytics that speed discovery and enable businesses to quickly derive meaningf...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In his Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, will explore t...
    DevOps has often been described in terms of CAMS: Culture, Automation, Measuring, Sharing. While we’ve seen a lot of focus on the “A” and even on the “M”, there are very few examples of why the “C" is equally important in the DevOps equation. In her session at @DevOps Summit, Lori MacVittie, of F5 Networks, explored HTTP/1 and HTTP/2 along with Microservices to illustrate why a collaborative culture between Dev, Ops, and the Network is critical to ensuring success.
    With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend @CloudExpo | @ThingsExpo, June 6-8, 2017, at the Javits Center in New York City, NY and October 31 - November 2, 2017, Santa Clara Convention Center, CA. Learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
    Everyone wants to use containers, but monitoring containers is hard. New ephemeral architecture introduces new challenges in how monitoring tools need to monitor and visualize containers, so your team can make sense of everything. In his session at @DevOpsSummit, David Gildeh, co-founder and CEO of Outlyer, will go through the challenges and show there is light at the end of the tunnel if you use the right tools and understand what you need to be monitoring to successfully use containers in your...
    What if you could build a web application that could support true web-scale traffic without having to ever provision or manage a single server? Sounds magical, and it is! In his session at 20th Cloud Expo, Chris Munns, Senior Developer Advocate for Serverless Applications at Amazon Web Services, will show how to build a serverless website that scales automatically using services like AWS Lambda, Amazon API Gateway, and Amazon S3. We will review several frameworks that can help you build serverle...
    The IT industry is undergoing a significant evolution to keep up with cloud application demand. We see this happening as a mindset shift, from traditional IT teams to more well-rounded, cloud-focused job roles. The IT industry has become so cloud-minded that Gartner predicts that by 2020, this cloud shift will impact more than $1 trillion of global IT spending. This shift, however, has left some IT professionals feeling a little anxious about what lies ahead. The good news is that cloud computin...
    An overall theme of Cloud computing and the specific practices within it is fundamentally one of automation. The core value of technology is to continually automate low level procedures to free up people to work on more value add activities, ultimately leading to the utopian goal of full Autonomic Computing. For example a great way to define your plan for DevOps tool chain adoption is through this lens. In this TechTarget article they outline a simple maturity model for planning this.
    While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations might...
    The rise of containers and microservices has skyrocketed the rate at which new applications are moved into production environments today. While developers have been deploying containers to speed up the development processes for some time, there still remain challenges with running microservices efficiently. Most existing IT monitoring tools don’t actually maintain visibility into the containers that make up microservices. As those container applications move into production, some IT operations t...