Welcome!

Microservices Expo Authors: Karthick Viswanathan, Elizabeth White, Mehdi Daoudi, Pat Romanski, Flint Brenton

Related Topics: Microservices Expo

Microservices Expo: Article

Demystifying Service-Oriented Architecture

Demystifying Service-Oriented Architecture

With the emergence of Web services into the mainstream the developer has to learn how to architect and build service-oriented systems. While service orientation isn't a new concept, the rapid convergence of the industry on Web services technology has brought the concept of service-oriented architectures (SOA) to the forefront of many developers' minds.

Over the last decade we learned how to construct software systems using patterns that adhered to the concepts of object orientation. Now, service orientation requires us to adapt to a new approach to system integration and application development. However, at the moment most of us are still learning about this new technology and so we tend to apply familiar patterns when building Web services–based applications.

Applying object-oriented patterns to service-based systems is generally a poor idea since the scale of a typical object-oriented application (generally within a single enterprise or department) is dwarfed by the scale of a Web services–based application (which may span many enterprises and departments). It is crucial to remember that the use of SOAP and WSDL in our applications does not constitute service orientation.

This article outlines the basics of (Web) service-oriented architectures and looks at the distinguishing features of SOA that make it the right approach to take when developing Web services–based applications. We define the concept of a service, compare the emerging service-oriented programming to object-oriented programming, and outline how to advance to SOA. Finally, we explore these concepts in the context of an example banking system.

What Is a Service?
In order to understand SOA, we must first understand what an individual service is. A service is a logical manifestation of some physical resources (like databases, programs, devices, or humans) grouped as a process that an organization exposes to the network. A Web service is therefore best thought of as a "user interface for computers" and, just like GUIs for human consumption, a Web service provides controlled access to some underlying computer system (see Figure 1).

 

A Web service is the set of actions that the hosting enterprise is prepared to execute. A Web service does not expose a set of operations, methods, or functions (though WSDL uses similar names). Instead, it advertises the set of structured messages that it will exchange. When a message is received by a Web service, the appropriate action is performed and a response message may be returned. There is no assumption that subsequent messages received are associated with prior ones (i.e., Web services are stateless), nor are services mutually dependent – the fact that we concentrate on message exchanges, rather than interfaces, supports this notion.

Service Orientation Versus Object Orientation
Perhaps the most important difference between service orientation and object orientation resides in the way software integration is achieved. Fundamental to object orientation is the concept of a type system that is shared among software components. In the general case, a hierarchy of interfaces has to be agreed upon in advance, before those software components can be integrated.

In contrast, services and their consumers achieve integration through the exchange of messages. The only thing that is shared between them is the vocabulary used to define the structure of those messages, which – in the case of Web services – are XML and XML Schema. The absence of a predefined type system enables loose coupling since no information needs to be shared among services and consumers, before implementation and deployment. Service orientation is more appropriate when (potentially heterogeneous) platforms are to be interconnected.

Furthermore, in object orientation, software entities (objects) are smaller units of abstraction than services (e.g., an account versus a bank). Hence, fine-grained interactions are encouraged between these objects and the formation of complicated webs of interrelations and dependencies between them (e.g., objects may hold references to other objects) cannot be avoided. Conversely, service orientation promotes coarse-grained interactions and the reduction of dependencies between services. In this view, we propagate "chunky" messages around a Web services–based application, which contains all the necessary information to invoke an action. Good service-oriented design mandates that all the information necessary to invoke an action is contained in a message, unlike object orientation where "chatty" interactions between client and serving object are the norm. Since Web services are likely to be remote from the application that consumes them, fine-grained interactions will perform poorly because of the overhead imposed by network communication (and indeed the additional XML infrastructure needed), and so it is imperative that coarsegrained interactions are supported. Once we have decomposed a problem domain into coarse-grained message exchanges supported by schemas to describe common vocabularies we are ready to step up to service-oriented architecture.

Stepping Up to SOA
The transition from object orientation to service orientation is not necessarily straightforward, because of inertia more than any real complexities of the approach. As developers and architects that have learned and used object-oriented patterns in distributed application design for more than a decade, we cannot expect to adapt overnight to this new architectural paradigm. Indeed, in the current world of Web services we see examples of old approaches to distributed application development presented as service orientation.

For example, early SOAP toolkits unwittingly encouraged an object view of the world by making SOAP RPC extremely easy to use, an approach that has been deprecated by the community through the WS-I basic profile. Current SOAP toolkits make it very easy to create a one-to-one association between a Web service and the implementing object (e.g., expose EJBs as Web services or create a WSDL of a Web service from a single class). A Web service should be more than that; it should be a front end to a set of objects, programs, databases, humans, etc. A particular symptom of this mindset is the use of the term "operation" in WSDL to describe the set of messages that are related to a particular action of a Web service. This is unhelpful since it has the same kind of connotation as terms like "method" and "function", where it is better to think in terms of messages. Thinking in terms of messages not only forces designers to think in terms of coarser granularities, but also detracts from the problematic notion of shared type systems where messages, not typed interfaces, are shared between components.

Stemming from this mindset, it is not uncommon to see Web services technologies used to violate enterprise encapsulation by exposing internal resources to the Web service consumers. This inevitably results in an integration nightmare and fragile applications where easily broken interrelationships can be formed that cross enterprise boundaries. We have seen examples of this in particular application domains, like the grid, where Web services are used to support characteristics like stateful interactions, service transience, factories, publicly visible state, and introspection, which are borrowed from object-based systems like CORBA and J2EE and applied to Web services in a manner that carries the danger of tight coupling. Effectively, a common component model is built on top of Web services when one is not required. Component models are ideal for building closed systems but are not suitable for enterprise-to-enterprise integration. The dangers of layering an object model on top of Web services technology are shown in Figure 2.

 

The Bank Service Example
The best way of demonstrating these concepts is by an example taken from our day-today lives, the "banking service." A banking service is an abstraction of a set of actions that are offered by the bank to authorized users. We may be able to open/close accounts, deposit/withdraw money, get/repay loans, transfer money from one bank to another, pay/cash checks, establish financial agreements, finance a business, and so on.

As customers of the bank, we don't have to see any of the underlying technologies, methodologies, resources, and practices that the bank uses in offering its services. We are free to use any of the available interfaces to access the same offerings albeit at different levels of quality of service. For example, we can use our computer at home, the telephone from work, one of the many ATMs on a street, or even walk into any of the branches of the bank whose service we want to access, as depicted in Figure 3. In all of these cases, the business logic is controlled by the banking service. We are merely presented with a human-toservice interface.

 

When interacting with our banking service through one of these interfaces we use a common problem domain vocabulary like the terms "account" and "money" or the actions "deposit" and "borrow" as the basis for message exchanges with the bank.

For example, when we want to withdraw money from our account, we are not presented with the actual account "object" and asked to withdraw the money via a "method call" on that object. We don't know, or need to know, how the information about our account is maintained by the bank. Instead, we interact with the bank through message exchanges that result in some money being withdrawn.

Taking this approach one step further, we can consider message exchange patterns provisioned through Web services technologies that enable other computing systems to interact with the bank. The way the bank manages its infrastructure and resources and the way it operates does not have to change – it's business as usual. Remember that Web services is an enabling technology for computer-to-computer interaction rather than a radical new way of doing business. So, even though our bank has deployed a set of Web services as a way to access its business logic, it still does not have to expose its internal resources, implementation details, or practices. What Web services have brought to our banking example is the ability to automate interactions that cross its administrative boundaries.

Now it's possible for programs running on computers that are not controlled by the bank to consume the banking service and, perhaps, combine it with business logic that is unknown to the bank. We can envisage a personal finance application that can talk directly to our bank through Web services and at the same time combine information from our credit card provider and stock broker to offer us an up-to-date view of our financial situation. Of course, a Web services–based approach enables us to scale this application up to enable the integration of our banking service into larger processes and its participation into automated business-to-business activities (see sidebar, "Service Interactions").

Conclusions
The advent of Web services means another paradigm shift for the development community. As with the previous paradigm shift to object orientation, we are going to have to learn (sometimes by our mistakes) how best to apply this new paradigm to designing and building our applications.

Though it is tempting to view this new style as objects-plus-XML, this is a strategy that will hamper the development of truly scalable and loosely coupled services. Instead, we should aim to deliver services that expose coarse-grained processes to our partners (and not simple get/set operations); we should build stateless services for loose coupling; and we should not expose (even conceptually) any resources from a service back end directly to a consumer because this makes applications brittle, and unable to cope with change.

Though these are simple rules of thumb (see sidebar, "SOA Checklist") and we expect our understanding of how to deploy this technology will become vastly more sophisticated in time, for now we believe these constraints are a good starting point to making applications truly service oriented.

Acknowledgements
We would like to thank Mike Sick from Serene Software for his valuable comments.

References

  • Web Services Architecture: www.w3.org/TR/ws-arch
  • Foster, I., et al. (2002) "The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration". Global Grid Forum.
  • Parastatidis, S., et al. (2003) "A Grid Application Framework Based on Web Services Specifications and Practices. www.neresc.ac.uk/projects/gaf
  • OASIS Web Services Business Process Execution Language: www.oasisopen.org/committees/wsbpel.
  • WS-Coordination: http://msdn.microsoft.com/ws/2002/08/WSCoor.
  • Web Services Context (WS-CTX): www.iona.com/devcenter/standards/WSCAF/WSCTX.pdf
  • Web Services Composite Application Framework (WS-CAF): www.iona.com/devcenter/standards/WS-CAF
  • Purdy, D. (2003) "Service Oriented Architecture" (presentation): www.douglasp.com/talks/web400.zip

    Service Interactions
    Some interaction patterns are more sophisticated than those offered by plain stateless Web services. For example, when we stand in front of an ATM we don't have to identify ourselves as part of every request for an action. Instead, we establish our identity and the account we want to operate on at the beginning of the interactions. Subsequent action requests take place within the "context" that has been established between us and the banking service (a feature that is implicit in an object-based system since we bind directly to a serving object).

    However, we can achieve similar contextual semantics with service interactions. Back-end resources like the account remain hidden from the service consumer, but we establish a context that we can use at the application level to "group" actions together. There are two possible approaches rising to prominence in the Web services community:

  • Correlation based on message content: This is best exemplified by the correlation-set mechanism in BPEL, where parts of messages incident on a Web service can be used to form a unique identifier, implicitly linking related messages together on such "keys" as account number, date, or suchlike.
  • WS-Coordination or WS-Context (part of the WS-CAF suite of specifications: A context identifying related messages is embedded in a SOAP header block on each related message.

    Which approach we choose is determined by our deployment scenario since both broadly achieve the same goal. Where the simplicity and potential interoperability benefits of a standard, explicit context–based approach are appealing, we need additional infrastructure to deal with context generation and lifetime management. Conversely, with the implicit correlation-based approach, we need no external infrastructure, though we run the risk of altering message content solely to be able to generate uniqueness (e.g., by adding a unique "message id" field where there is no business-level requirement).

    Whichever context form is selected, the upshot is the same: context allows consumers to have "stateful" interactions with Web services, but does not require back-end objects to be exposed. This means the Web service has a free hand in deciding how to manage its back-end resources, since they remain encapsulated away from the consumer. This is in contrast to the object-based approach, where invocation context is set by references to objects and the invocation history of referenced objects. The big drawback with this scheme is that object references between enterprises are likely to be brittle and impose too tight a level of coupling between the client and the serving object.

    SOA Checklist

  • Service orientation focuses on shared message structure, not shared type systems.
  • Messages carry sufficient data to allow the action to be completed, and are coarse grained.
  • Service orientation encourages loose coupling, but does not guarantee it.
  • WSDL is a contract language that specifies message structure and permitted message exchange patterns, and is categorically not an object IDL.
  • 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

    Comments (8) 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
    Savas Parastatidis 11/25/03 11:54:35 AM EST

    Dear Greg,

    Thank you very much for your interesting comments.

    I mostly agree with your description of a service. To me a service is an entity (possible a software one) that adheres to a contract. A contract defines the format of messages that the service may send and receive. A contract also defines the message exchange patterns in which the service is prepared to participate.

    I totally agree with you that the Web Services Architecture is a realisation (one of the possible many) of the SOA concepts. In fact, one could argue that CORBA services attempted to implement the same concepts. I believe that CORBA services were a step towards the right direction but they still had to carry the "garbage" of the globally shared type system for one single application. This is not so with Web Services where we only share the knowledge XML, XML Schema, SOAP, and perhaps WSDL.

    As for notification... Notification is a pattern and as such I don't see why you think it's not implementable in a service-oriented world. You could have a look at the myGrid notification service (a research project) at http://www.mygrid.org.uk for such a service.

    SOA does not impose a request-response pattern. You may have different message exchange patterns defined by a contract.

    Regards,
    .savas.

    Savas Parastatidis 11/25/03 11:54:10 AM EST

    Dear Simon,

    Thank you for very much for your feedback. As you probably already know from this article and you will see from two future articles, Jim and I disagree with your view. We do believe that there is a difference between object- and service-orientation. The former is built around the concepts of objects and classes while central to the latter are messages and contracts.

    Is service-orientation something new? Of course not. As with most things in computing, it's an evolutionary step. We rarely see revolutionary ones.

    Have we been doing service-orientation with CORBA? To a certain extent, yes. The benefits of loose-coupling, interoperability, scalability, and boundary preservation are not new in distributed computing. Service-oriented architectures (SOAs) didn't just introduce them. We have been trying to build distributed applications with such characteristics for years. Service-orientation is another paradigm that aims to further enable the implementation of such applications.

    The Web Services Architecture (WSA) is a realisation of the SOA concepts and an evolutionary step in our efforts to build more loosely-coupled, scalable distributed applications.

    Some more comments are inline...

    >
    > From: Simon Thompson
    >
    > Subject: Very questionable statements.
    >
    > E-Mail Address: simon.2.thompson-at-bt.com
    >
    > Message: "The absence of a predefined type system enables loose
    > coupling since no information needs to be shared among services and
    > consumers, before implementation and deployment."
    > - I think this statement is nonsense, first of all information
    > definitely has to be shared in the form of the rpc interface, the
    > types in the rpc interface and the natural language description of the
    > service functionality. I think that type is a conceptual shorthand /
    > abstraction for the above information and that its absence is an
    > impediment to loose coupling rather than a enabling factor.

    You have just described the role of Interface Description Languages (IDLs). Their role in this world is to describe interfaces of instances of a shared type, a shared abstraction. Once that is done, methods on those instances may be invoked remotely.

    That is not so in SOAs where we agree on the format of the messages that are exchanged between services. There is no concept of a remote procedure call. In fact, we don't even know whether a service is implemented in a language that supports procedures or objects. The only thing we know is that if a service is given a message of a particular format, we may get (according to the message exchange pattern) a reply in the form of another message with a well-define structure. The description of the message formats and the exchange patterns makes the contract. We hope to have an article on this exact topic very shortly. Stay tuned.

    > "We have seen examples of this in particular application domains, like
    > the grid, where Web services are used to support characteristics like
    > stateful interactions, service transience, factories, publicly visible
    > state, and introspection, which are borrowed from object-based systems
    > like CORBA and J2EE and applied to Web services in a manner that
    > carries the danger of tight coupling."
    > 1. The GRID is not an application domain, it is an infrastructure.
    > 2. Factories and introspection are tools that permit loose
    > coupling by breaking the link between instantiation and interface.

    I disagree with your statement that "the Grid is not an application domain, it is an infrastructure". Granted, the Grid means different things to different people. However, we were referring to the specific efforts within the Global Grid Forum and the Open Grid Services Infrastructure (OGSI) specification. The Grid is an application domain and OGSI defines the infrastructure for it, according to those involved in most of the GGF working groups. The Grid is an application domain with its own requirement. It is nothing new in terms of distributed computing. It just imposes new challenges on how the distributed computing concepts can be applied at a large scale.

    We believe that OGSI defines an object-based component model on top of Web Services, which is fine. In fact, during discussions in the last GGF meeting, the OGSI authors agreed that to be the case (look for Dr. David Snelling's presentation at the OGSI WG web site, https://forge.gridforum.org/projects/ogsi-wg). It's just that we believe it is possible and preferable to build Grid applications without the concepts introduced by OGSI but, instead, with just Web Services.

    I agree with your second statement. These are indeed useful tools in an object-oriented view of the world. However, in a service-oriented world, they are not really necessary. You don't create an instance of your favourite banking service in order to withdraw some money, do you? Services are there, they exist, they are offered by a service provider.

    > "When interacting with our banking service through one of these
    > interfaces we use a common problem domain vocabulary like the terms
    > "account" and "money" or the actions "deposit" and "borrow" as the
    > basis for message exchanges with the bank.
    > For example, when we want to withdraw money from our account, we are
    > not presented with the actual account "object" and asked to withdraw
    > the money via a "method call" on that object. We don't know, or need
    > to know, how the information about our account is maintained by the
    > bank. Instead, we interact with the bank through message exchanges
    > that result in some money being withdrawn."
    > 1. Which type of account - no notice, high interest, check-in,
    > deposit, mortgage? Money - currency type, transfer mechanism? Borrow -
    > repayment terms, interest rate?

    The one described by the contract, the WSDL.

    > 2. Surely a method call simply is a way of sending a message to an
    > object? Surely information/implementation hiding is at the core of OO?
    >

    Sure, you can hide implementation technologies behind an interface and you can have information encapsulation in a distributed object-oriented environment. Technologies like CORBA, DCOM, JavaRMI, etc. tried to do that but not with great success. They made too many assumptions on what it is shared between the different distributed components of the entire system (i.e., types). In Web Services we only share knowledge of XML and XML Schema for messages and we have a way to describe contracts (i.e., WSDL).

    Again, thank you for your comments.

    Best regards,
    --
    Dr. Savas Parastatidis
    http://savas.parastatidis.name

    Greg Wdowiak 11/13/03 06:41:15 PM EST

    In addition to Iyad's comments that I agree with:

    1) To me the SOA is an approach to constructing enterprise systems from components in which:

    - a system consists of a COLLECTION of interacting services, each of which providing a well-defined collection of functionality, available over the network.

    - at the core of an SOA system is a service. A service is a DISCOVERABLE software entity that offers coarse-grained functionality through well-defined, published interface. A service is offered by a service provider ? a software entity that implements the service specification.

    -- a service is accessed by a service requestor. A service requestor may be a client application or a service itself.

    -- SOA is enabled by an SOA broker. An SOA broker (be it centralized or distributed) provides:
    a) Service registry is a special service that maintains a database of services (service interfaces and service providers) and provides a lookup facility to this database. Service providers publish service interfaces to the service registry. Service requestors browse the service registry, discover the services and invoke them.

    -- Service invocation infrastructure allows the service requestors to bind to a service and invoke it .

    2) The Web Services architecture is a popular EXAMPLE of SOA. Conceivably SOA may be implemented without Web Services at all!

    3) An interesting question is:
    - does SOA impose a request-response type of interactions (typical for consolidated application type of interagration)? if so -- how to reconcile event driven applications (for example data integration where change in data in system A is propagated to other systems) with SOA ....

    Simon Thompson 11/11/03 05:50:55 AM EST

    "The absence of a predefined type system enables loose coupling since no information needs to be shared among services and consumers, before implementation and deployment."
    - I think this statement is nonsense, first of all information definitely has to be shared in the form of the rpc interface, the types in the rpc interface and the natural language description of the service functionality. I think that type is a conceptual shorthand / abstraction for the above information and that its absence is an impediment to loose coupling rather than a enabling factor.
    "We have seen examples of this in particular application domains, like the grid, where Web services are used to support characteristics like stateful interactions, service transience, factories, publicly visible state, and introspection, which are borrowed from object-based systems like CORBA and J2EE and applied to Web services in a manner that carries the danger of tight coupling."
    1. The GRID is not an application domain, it is an infrastructure.
    2. Factories and introspection are tools that permit loose coupling by breaking the link between instantiation and interface.
    "When interacting with our banking service through one of these interfaces we use a common problem domain vocabulary like the terms "account" and "money" or the actions "deposit" and "borrow" as the basis for message exchanges with the bank.
    For example, when we want to withdraw money from our account, we are not presented with the actual account "object" and asked to withdraw the money via a "method call" on that object. We don't know, or need to know, how the information about our account is maintained by the bank. Instead, we interact with the bank through message exchanges that result in some money being withdrawn."
    1. Which type of account - no notice, high interest, check-in, deposit, mortgage? Money - currency type, transfer mechanism? Borrow - repayment terms, interest rate?
    2. Surely a method call simply is a way of sending a message to an object? Surely information/implementation hiding is at the core of OO?

    Savas Parastatidis 11/06/03 10:20:15 AM EST

    Dear Iyad,

    >
    > Thank you for your candid response. We might be in disagreement and
    > that is ok.

    Yes, of course it is :-) If we were all in agreement we wouldn't have
    anything to write and talk about :-)

    > However, I would really like to understand the points you raise in a
    > little more details out of a genuine interest in learning something
    new.
    > Even after reading your response and one of the referenced articles by

    > Don Box, I still stand by the notion that SOA is a natural evolution
    > of distribute OO (DOO). There are a lot of commonality and some
    > implementation differences and some subtle but important conceptual
    > differences?which I would defer so we can keep the dialog to a
    > manageable scope.
    >

    I don't think we've ever suggested that SOA was not a natural evolution
    of OO. Also, we don't see SOA as a replacement to the OO paradigm. They
    complement each other. Remember from the old days when we moved from
    procedural languages to C++? There were people doing something very
    close to objects in C and then there were those who used C++ to write
    programs in the same way as when they were using C. I believe we are now
    in a transitional period like that one. The SOA model makes fewer
    assumptions than the OO one. Yes, you can do service-orientation using
    object-oriented technologies. CORBA services was a move towards that
    model. However, you still had to carry some of the "baggage" of a
    distributed object system.

    Web Services is a clean, new approach to service-orientation where we
    concentrate on messages exchange patterns and the structure of those
    messages rather than interfaces, types, references, instances, etc.

    > Before we get into the specifics, I would like to comment on the
    > article by Don Box. I thought it was a good article with good insight
    > into Microsoft Indigo. However, I don't think it was neither fair nor
    > accurate in comparing SOA as a concept and architecture vs. OO as an
    > implementation in the Service-orientation Fundamentals section. As an
    > example, it compares the deployment of services in SOA vs.
    > applications in OO and all of the version/binary-compatibility
    > challenges. There is nothing inherent in SOA that will make deployment

    > of a particular implementation of a service any easier or harder than
    > in any other distributed architecture. His example of amazon.com holds

    > true even if they have used CORBA. In a matter of fact, one of the
    > principle goals of CORBA is that an IDL can exist far before you have
    > any implementation or consumers of it, regardless of adopted
    technology.
    >

    I saw all Don Box's talks last week at Microsoft's PDC and I totally
    agree with him. We have the same approach with him and he is one of the
    main thinkers behind XML, SOAP, SOA, etc.

    With CORBA IDL you assume that you have a common understanding about the
    objects in your system. You assume common knowledge of their interfaces
    and their behaviour. If one of those changes, your entire distributed
    application breaks.

    That's no so in SOA and Web Services. Amazon.com can evolve but
    applications that already use it will not break because one of the
    characteristics of services is that they can evolve independently. I
    have yet to see a distributed object-based system where that is the
    case. With services the only common think you have is the way you
    validate the messages exchanged. A service may be prepared to accept
    arbitrary content in order to allow for future evolution (e.g., XML
    Schema extensibility elements).

    > Nevertheless, the author does state that SOA complements OO, not
    > supersedes it?which I?m in total agreement with, and was the main
    > point I was making in my previous email (different patterns for
    > interface layer vs. app logic layer).
    >

    I think that there is room for both at different levels. In fact, our
    next article in WSJ, which has already been submitted, talks exactly
    about how one could combine SOA and OO techniques in building
    distributed applications. OO could be used as the implementation
    technology for a service.

    > Back to your article and to help us get on common grounds. Here are
    few
    > points of what I think SOA is/isn't and I would like to know whether
    you
    > agree with these points:
    >
    > - In a full implementation of logic, SOA is appropriate for the
    > interface/facade layer, but not the concrete/detail implementation of
    the
    > logic. In other words, I don't believe that everything is a service
    and a
    > service invocation, kind of like the motto in OO that everything is an
    > object. If you agree with this then it's not fair to compare OO to
    SOA.
    > Instead you should compare SOA to the various DOO architectures.

    I think that's what we are doing. We are talking about distributed
    systems and how to build distributed applications using service
    orientation. We are suggesting that OO is good for closed systems
    (distributed or not) while SOA is better for bringing together open,
    evolvable, loosely coupled, perhaps cross-organisation, with well
    defined boundaries systems.

    > - WSDL provides a description of what a service is capable of
    performing
    > (as
    > in behavior) and all of the data elements that are involved in using a
    > service (structure). These data elements are well defined and can be
    > either
    > simple (primitive) or complex (compound elements), and are strongly
    typed
    > (including wildcards like xsd:any). If you agree with this, then I
    would
    > like to know how this differs than an interface in an IDL where it
    > contains
    > a list of operations that the interface supports and the parameters
    > (in/out)
    > that it requires. These parameters can be primitive types, structs, or
    > references to other interfaces (which lacks in WSDL, but I believe
    will be
    > later added--which you disagree with).

    I don't agree with your description of WSDL. WSDL is a contract not an
    interface description language (...look for another article about that,
    coming soon to your favourite journal about Web Services :-)

    WSDL defines the structure of the messages being exchanged and nothing
    more. If a WSDL document defines that a service will send me a message
    containing an XML representation of a Person, I have no idea about the
    internal representation of a Person in that service. With IDL, there is
    such an assumption. I either get the Person object by value or by
    reference but in both cases there is the common understanding of what a
    Person is in terms of an interface and behaviour. In Web Services all we
    agree on is how to validate the XML that we exchange.

    > - If you agree with my description of WSDL above, then don't you see
    how
    > both the consumer and provider of a service are sharing a common
    > understanding of types in the system. If the schema changes in a given
    > WSDL
    > to extend some implementation, wouldn't this also break all consumers
    of
    > this service? However, if you're referring to changing a parameter
    type of
    > an operation in a Java remote interface, or adding a new operation
    > altogether, then you're correct this will break all live applications
    that
    > depend on this interface even if they don't use the effected
    operation.
    > Nevertheless, this is a limitation of a Java-centric implementation of
    > DOO,
    > not DOO itself. Doing the same to a CORBA IDL, on the other hand,
    would
    > not
    > effect any of the life implementations or consumers of the service.

    As you see above, I don't agree with your view on what WSDL does. I
    agree that if one was to change the XML Schema of a Person, then
    applications that had a previous understanding will not work anymore.
    However, the thing with SOA is that services are isolated and not under
    our control. Hence, we do not see a service as part of a closed system,
    as it is usually the case with CORBA. Hence, a service provider will
    think really hard before changing the XML Schema for the contents of a
    message.

    Having said that, it's much easier to evolve the XML Schema without
    breaking existing applications that use a service than it is to evolve a
    CORBA IDL and the applications that depend on it.

    > - You said that there are misuses in SOA already, but the same is true
    in
    > OO
    > and DOO. I've seen IDLs, for example, that had fine-grained
    interfaces,
    > but
    > that usually didn't survive even the first deployment of such a
    system.
    > Developers quickly recognize the performance hit and are forced to
    > restructure the IDL into coarse-grained interfaces. Interfaces are not
    > much
    > different than you would see in a WSDL, or even in a SessionBean, with
    > operations that take all the necessary parameters in one shot and
    return a
    > complete answer (if need be). Most of are stateless, but some are
    > statefull
    > and do use references from previous message exchange (not much
    different
    > than correlation). In a matter of fact, IORs in CORBA (I think I got
    the
    > initials right--been a while), have built in mechanism to support
    long-
    > lived
    > data that are specific to the referenced object at the logical level,
    not
    > just the default auto generated UUID. Nothing in this exposes the
    > internals
    > of the implementation.
    >

    As I said earlier, you can do service-orientation using object-oriented
    technologies. Some of the approaches in the CORBA world led towards the
    same methodologies for building distributed systems (e.g., stateless
    interactions, coarse-grained interfaces, lazy binding, etc.). In our
    article we tried to show that when building Web Services applications
    the SOA concepts are more appropriate than using .NET remoting, Java
    RMI, CORBA, DCOM, etc. (to name a few).

    > I believe that SOA is an evolutionary step in the industry with
    > revolutionary impact. Just like HTML/HTTP/TCP/IP were the foundation
    of
    > the
    > Internet boom, having the entire industry agreeing on a set of
    standards
    > like SOAP and WSDL, for example, will grow the use of the Internet
    (both
    > in
    > depth and breadth) far beyond anything we?ve imagined. However, even
    > though
    > XML and XML Schema have some advantages over IIOP, if the entire
    industry
    > agreed on IIOP, the same impact can be achieved. The article about
    Indigo
    > that you've referenced is a great example of how similar most of the
    > services in a SOA implementation to CORBA services. A lot of
    developers
    > looked at CORBA as just an ORB, while it's a comprehensive
    architecture of
    > building and integrating distributed applications that can span the
    globe
    > and are developed at different times by different parties. I know that
    I
    > sound like a big CORBA supporter, but that is not the case. I'm just
    > pointing out similarities with existing architectures so we can
    leverage
    > the
    > lessons learned, and highlight the important differences.

    As I said above, I believe that CORBA services were a step to the right
    direction but CORBA in general carried a lot of assumptions because of
    its heritage. SOA and Web Services are an evolutionary step. No
    disagreement there.

    Also, I disagree with your comment about CORBA and standards. There has
    been a CORBA standard for a long time. However, because of its
    complexity and ambiguities we had a hard time making different ORBs work
    together. XML and SOAP are very simple and I think that's a great
    advantage over CORBA.

    >
    > I also believe that there is a great marriage between SOA and OO. OO
    > programming languages make great implementation platforms for SOA
    > services.
    > I think that C# in .NET and Java with TME Glue (now webMethods Glue)
    make
    > good examples of my statement. Both support code-first and WSDL-first
    > development models. Mapping services to facade interfaces/objects are
    very
    > natural, and using OO for building the detailed implementation
    leverages
    > the
    > advantages of OO over procedural languages. However, both can be
    properly
    > used and misused in building web services.
    >

    And it is the misuse of such technologies when building Web Services
    that we wanted to point out. Look for our next article which discusses
    the implementation related issues.

    > Will be interested in your feedback.
    >

    Again, thank you for your very interesting comments.

    Regards,
    .savas.

    Iyad Jabri 11/05/03 12:46:16 AM EST

    Dear Savas,

    Thank you for your candid response. We might be in disagreement and that is ok. However, I would really like to understand the points you raise in a little more details out of a genuine interest in learning something new. Even after reading your response and one of the referenced articles by Don Box, I still stand by the notion that SOA is a natural evolution of distribute OO (DOO). There are a lot of commonality and some implementation differences and some subtle but important conceptual differences?which I would defer so we can keep the dialog to a manageable scope.

    Before we get into the specifics, I would like to comment on the article by Don Box. I thought it was a good article with good insight into Microsoft Indigo. However, I don't think it was neither fair nor accurate in comparing SOA as a concept and architecture vs. OO as an implementation in the Service-orientation Fundamentals section. As an example, it compares the deployment of services in SOA vs. applications in OO and all of the version/binary-compatibility challenges. There is nothing inherent in SOA that will make deployment of a particular implementation of a service any easier or harder than in any other distributed architecture. His example of amazon.com holds true even if they have used CORBA. In a matter of fact, one of the principle goals of CORBA is that an IDL can exist far before you have any implementation or consumers of it, regardless of adopted technology.

    Nevertheless, the author does state that SOA complements OO, not supersedes it?which I?m in total agreement with, and was the main point I was making in my previous email (different patterns for interface layer vs. app logic layer).

    Back to your article and to help us get on common grounds. Here are few points of what I think SOA is/isn't and I would like to know whether you agree with these points:

    - In a full implementation of logic, SOA is appropriate for the interface/facade layer, but not the concrete/detail implementation of the logic. In other words, I don't believe that everything is a service and a service invocation, kind of like the motto in OO that everything is an object. If you agree with this then it's not fair to compare OO to SOA. Instead you should compare SOA to the various DOO architectures.
    - WSDL provides a description of what a service is capable of performing (as in behavior) and all of the data elements that are involved in using a service (structure). These data elements are well defined and can be either simple (primitive) or complex (compound elements), and are strongly typed (including wildcards like xsd:any). If you agree with this, then I would like to know how this differs than an interface in an IDL where it contains a list of operations that the interface supports and the parameters (in/out) that it requires. These parameters can be primitive types, structs, or references to other interfaces (which lacks in WSDL, but I believe will be later added--which you disagree with).
    - If you agree with my description of WSDL above, then don't you see how both the consumer and provider of a service are sharing a common understanding of types in the system. If the schema changes in a given WSDL to extend some implementation, wouldn't this also break all consumers of this service? However, if you're referring to changing a parameter type of an operation in a Java remote interface, or adding a new operation altogether, then you're correct this will break all live applications that depend on this interface even if they don't use the effected operation. Nevertheless, this is a limitation of a Java-centric implementation of DOO, not DOO itself. Doing the same to a CORBA IDL, on the other hand, would not effect any of the life implementations or consumers of the service.
    - You said that there are misuses in SOA already, but the same is true in OO and DOO. I've seen IDLs, for example, that had fine-grained interfaces, but that usually didn't survive even the first deployment of such a system. Developers quickly recognize the performance hit and are forced to restructure the IDL into coarse-grained interfaces. Interfaces are not much different than you would see in a WSDL, or even in a SessionBean, with operations that take all the necessary parameters in one shot and return a complete answer (if need be). Most of are stateless, but some are statefull and do use references from previous message exchange (not much different than correlation). In a matter of fact, IORs in CORBA (I think I got the initials right--been a while), have built in mechanism to support long-lived data that are specific to the referenced object at the logical level, not just the default auto generated UUID. Nothing in this exposes the internals of the implementation.

    I believe that SOA is an evolutionary step in the industry with revolutionary impact. Just like HTML/HTTP/TCP/IP were the foundation of the Internet boom, having the entire industry agreeing on a set of standards like SOAP and WSDL, for example, will grow the use of the Internet (both in depth and breadth) far beyond anything we?ve imagined. However, even though XML and XML Schema have some advantages over IIOP, if the entire industry agreed on IIOP, the same impact can be achieved. The article about Indigo that you've referenced is a great example of how similar most of the services in a SOA implementation to CORBA services. A lot of developers looked at CORBA as just an ORB, while it's a comprehensive architecture of building and integrating distributed applications that can span the globe and are developed at different times by different parties. I know that I sound like a big CORBA supporter, but that is not the case. I'm just pointing out similarities with existing architectures so we can leverage the lessons learned, and highlight the important differences.

    I also believe that there is a great marriage between SOA and OO. OO programming languages make great implementation platforms for SOA services. I think that C# in .NET and Java with TME Glue (now webMethods Glue) make good examples of my statement. Both support code-first and WSDL-first development models. Mapping services to facade interfaces/objects are very natural, and using OO for building the detailed implementation leverages the advantages of OO over procedural languages. However, both can be properly used and misused in building web services.

    Will be interested in your feedback.

    Savas Parastatidis 11/04/03 06:57:51 PM EST

    Dear Iyad,

    Obviously, as you read from our article, we do not share your view. We actually see a difference between Service-Orientation and Object-Orientation. In Object-Orientation, it is necessary to share an understanding about the underlying type system and the behaviours that are realised through the sharing of interfaces/types. Type sharing results in systems that cannot evolve easily, especially when they are distributed and not under a single entity?s control. The evolution of one interface/class may break the entire system. The result is tight coupling.

    Services on the other hand are deployed, implemented, and maintained independently. They have well defined boundaries and they communicate with others through messages. The only common understanding that is shared between services is how to do message validation. Services define the message-exchange patterns and formats of those messages that they are willing to accept. Hence, loose-coupling is achieved.

    In Object-Oriented system we share behaviours and an entire type system, not just message formats.

    Pass-by-reference is a valuable pattern in cases where we are in control of the entire system as it results to tight coupling. In a SOA environment, it would result in resources being exposed outside a service?s well defined boundaries. I expect that in some cases (e.g., huge datasets) a form of pass-by-reference will be created but not as we know it. It is not within the scope of SOA to expose objects/resources/entities in that manner. Access to such resource could be achieved through contextualisation (e.g., WS-Addressing).

    After Jim and I submitted this article to the WSJ, we found out that we were not alone in our understanding of SOA when compared to OO. In fact, influential people like Don Box [1] & [2] have very similar ideas (or, I should probably say that we have similar ideas to him:-)

    1. Box, D., Service-Oriented Architecture and Programming (SOAP) - Part 1 & Part 2 talks from the MSDN TV archive (http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030827SO..., http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030902SO...). 2003.

    2. http://msdn.microsoft.com/Longhorn/understanding/mag/default.aspx?pull=/...

    Iyad Jabri 11/03/03 11:07:45 PM EST

    With all due respect, I totally disagree with the author?s comparison between SOA and OO. In a matter of fact, any architect/developer that built distribute object-oriented systems knows to apply different patterns to interface objects vs. implementation objects. For example, interface objects are coarse-grained in comparison to the fine-grained implementation objects. In addition, the implementation objects are completely encapsulated (which is one of the fundamental principles of OO?distributed or not), and are never visible to the outside world except if they were value holder?not much different than complex XML elements described in a WSDL.

    The statement that WSDL is so much different than an interface declaration of an interface object (like in an IDL for example) is also not valid. Both describe the terms of a contract between the provider and the consumer. True, pass-by-value was not part of CORBA 1.0, however, it was quickly added before CORBA gained traction. Web services, on the other hand, concentrates solely on pass-by-value (to use IDL terms)?for now:-). I believe support to pass-by-reference, probably in the form of URI, is going to make it into the evolution of SOA. It is interesting how with every new technology trend, we tend to start from an opposite extreme, just to meet back somewhere in the middle.

    As a reader, I felt that the article is more mystifying SOA than demystifying it. I agree with the author that Web services are the user interface of a system (more for computers than humans?which is not completely accurate), accordingly, I believe they should be treated as such. In building n-tier systems, we use different patterns for objects that make up the interface layer (top tier) vs. the application logic layer (middle tier). Web services provides us with standards for building the interface layer where new systems can discover and interact with our system, just as a human user discovers a web site and uses HTML to interact with a web application. SOA will play a role in the middle tier, but just as a middleware providing transparent connectivity to the distributed pieces of application logic. Anything more than this is simply mystifying the subject.

    That said, there are subtle but important differences that SOA brings to pure distributed OO development. However, these would be better addressed as a new article/thread.

    @MicroservicesExpo Stories
    These days, APIs have become an integral part of the digital transformation journey for all enterprises. Every digital innovation story is connected to APIs . But have you ever pondered over to know what are the source of these APIs? Let me explain - APIs sources can be varied, internal or external, solving different purposes, but mostly categorized into the following two categories. Data lakes is a term used to represent disconnected but relevant data that are used by various business units wit...
    There is a huge demand for responsive, real-time mobile and web experiences, but current architectural patterns do not easily accommodate applications that respond to events in real time. Common solutions using message queues or HTTP long-polling quickly lead to resiliency, scalability and development velocity challenges. In his session at 21st Cloud Expo, Ryland Degnan, a Senior Software Engineer on the Netflix Edge Platform team, will discuss how by leveraging a reactive stream-based protocol,...
    Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reducti...
    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...
    Enterprises are moving to the cloud faster than most of us in security expected. CIOs are going from 0 to 100 in cloud adoption and leaving security teams in the dust. Once cloud is part of an enterprise stack, it’s unclear who has responsibility for the protection of applications, services, and data. When cloud breaches occur, whether active compromise or a publicly accessible database, the blame must fall on both service providers and users. In his session at 21st Cloud Expo, Ben Johnson, C...
    Many organizations adopt DevOps to reduce cycle times and deliver software faster; some take on DevOps to drive higher quality and better end-user experience; others look to DevOps for a clearer line-of-sight to customers to drive better business impacts. In truth, these three foundations go together. In this power panel at @DevOpsSummit 21st Cloud Expo, moderated by DevOps Conference Co-Chair Andi Mann, industry experts will discuss how leading organizations build application success from all...
    ‘Trend’ is a pretty common business term, but its definition tends to vary by industry. In performance monitoring, trend, or trend shift, is a key metric that is used to indicate change. Change is inevitable. Today’s websites must frequently update and change to keep up with competition and attract new users, but such changes can have a negative impact on the user experience if not managed properly. The dynamic nature of the Internet makes it necessary to constantly monitor different metrics. O...
    The last two years has seen discussions about cloud computing evolve from the public / private / hybrid split to the reality that most enterprises will be creating a complex, multi-cloud strategy. Companies are wary of committing all of their resources to a single cloud, and instead are choosing to spread the risk – and the benefits – of cloud computing across multiple providers and internal infrastructures, as they follow their business needs. Will this approach be successful? How large is the ...
    Agile has finally jumped the technology shark, expanding outside the software world. Enterprises are now increasingly adopting Agile practices across their organizations in order to successfully navigate the disruptive waters that threaten to drown them. In our quest for establishing change as a core competency in our organizations, this business-centric notion of Agile is an essential component of Agile Digital Transformation. In the years since the publication of the Agile Manifesto, the conn...
    You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
    The nature of the technology business is forward-thinking. It focuses on the future and what’s coming next. Innovations and creativity in our world of software development strive to improve the status quo and increase customer satisfaction through speed and increased connectivity. Yet, while it's exciting to see enterprises embrace new ways of thinking and advance their processes with cutting edge technology, it rarely happens rapidly or even simultaneously across all industries.
    Most of the time there is a lot of work involved to move to the cloud, and most of that isn't really related to AWS or Azure or Google Cloud. Before we talk about public cloud vendors and DevOps tools, there are usually several technical and non-technical challenges that are connected to it and that every company needs to solve to move to the cloud. In his session at 21st Cloud Expo, Stefano Bellasio, CEO and founder of Cloud Academy Inc., will discuss what the tools, disciplines, and cultural...
    With the rise of DevOps, containers are at the brink of becoming a pervasive technology in Enterprise IT to accelerate application delivery for the business. When it comes to adopting containers in the enterprise, security is the highest adoption barrier. Is your organization ready to address the security risks with containers for your DevOps environment? In his session at @DevOpsSummit at 21st Cloud Expo, Chris Van Tuin, Chief Technologist, NA West at Red Hat, will discuss: The top security r...
    "NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    The “Digital Era” is forcing us to engage with new methods to build, operate and maintain applications. This transformation also implies an evolution to more and more intelligent applications to better engage with the customers, while creating significant market differentiators. In both cases, the cloud has become a key enabler to embrace this digital revolution. So, moving to the cloud is no longer the question; the new questions are HOW and WHEN. To make this equation even more complex, most ...
    Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
    One of the biggest challenges with adopting a DevOps mentality is: new applications are easily adapted to cloud-native, microservice-based, or containerized architectures - they can be built for them - but old applications need complex refactoring. On the other hand, these new technologies can require relearning or adapting new, oftentimes more complex, methodologies and tools to be ready for production. In his general session at @DevOpsSummit at 20th Cloud Expo, Chris Brown, Solutions Marketi...
    Leading companies, from the Global Fortune 500 to the smallest companies, are adopting hybrid cloud as the path to business advantage. Hybrid cloud depends on cloud services and on-premises infrastructure working in unison. Successful implementations require new levels of data mobility, enabled by an automated and seamless flow across on-premises and cloud resources. In his general session at 21st Cloud Expo, Greg Tevis, an IBM Storage Software Technical Strategist and Customer Solution Architec...
    Today companies are looking to achieve cloud-first digital agility to reduce time-to-market, optimize utilization of resources, and rapidly deliver disruptive business solutions. However, leveraging the benefits of cloud deployments can be complicated for companies with extensive legacy computing environments. In his session at 21st Cloud Expo, Craig Sproule, founder and CEO of Metavine, will outline the challenges enterprises face in migrating legacy solutions to the cloud. He will also prese...
    DevOps at Cloud Expo – being held October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA – announces that its Call for Papers is open. Born out of proven success in agile development, cloud computing, and process automation, DevOps is a macro trend you cannot afford to miss. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the world's largest enterprises – and delivering real r...