We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

How Can We Differentiate a SOA Implementation Using Standards From 'Generic' SOA?

Vote 0 Votes
From John Power at Risaris: The term 'SOA' originally implied to an architecture which used standard technologies, primarily SOAP, WSDL and so on, to implement services that could be discovered and used in a non proprietary fashion. It has now become a generic term such that any architecture that implements 'services', even if they are called in a proprietary fashion, is a being refferred to as 'SOA'. How can we distinguish between a SOA implemented using these standards, which offers non proprietary interoperability, from 'generic SOA', which does not? 'Standards Based SOA' perhaps?

11 Replies

| Add a Reply
  • I always think about it using an OO-style metaphor. SOA is the class, and specific, standards-based implementations--like a collection of SOAP services secured with OASIS Web Services Security standards--are instances. The class is very important; but it's the instance where the rubber hits the road.

  • SOA is an architectural style, standards are a way of implementing SOA architecture. Given historical baggage, "standards" tend to connote web services, as those are the best known SOA standards. But deservedly, "standard" SOA has drawn a bad rap owing to the complexity and extremely long tail of WS-* standards, which is cluttered with overlapping and obscure protocols.

    Put another way, if one tree in the forest implements a standard, would you consider it a standard? Welcome to the world of web services.

  • I'm going to reiterate my definition from my most recent blog entry:

    For me, SOA is defined precisely as follows:

    Service-Oriented Architecture (SOA) is an archetype—an architectural pattern—that focuses on design of systems from the perspective of providers and consumers as defined by a contract. SOA-based designs introduce agility by enabling interchangeability of service providers without requiring process changes in the consumers. Hence, the SOA is applied at the system level, not just at a single component within a system.

    If this is accomplished, the underlying technologies is irrelevant.

  • user-pic

    John Power has mentioned standards of Web Services that are not SOA but only one of possible interface implementations.

    If you want to deal with SOA standards, look into OASIS SOA standards and coming ones from OMG and The Open Group.

    If the service provider cares about "non proprietary interoperability" for Web Services, it will, probably, use WS* standards for this. Otherwise, it can do whatever it wants and call it SOA whilst its 'services' operate according to principles of service orientation.

  • I am not sure there is an easy way to distinguish between standard verse generic but the key drive between using one over the other should be “interoperability?. If the motivation is to create services that are going to be reused and provide the greatest value than the usage of standards should be key.

    As you can see from the short definition on Wikipedia "interoperability" is a key requirement for SOA.

    In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems package functionality as interoperable services. A SOA infrastructure allows different applications to exchange data with one another.

  • I agree with many of the other commenters here: SOA is an architectural style. Interoperability is vital - because (as JP Morgenthal says) SOA is a system-level attribute - but use of particular Web Services standards is not critical to the "SOA-ness" of a system.
    A parallel: think of cellphone networks. In Europe, the vast majority of our networks use GSM-based protocols like GPRS for data services; whereas in the US GSM has only recently become part of the landscape. Before then it was all CDMA/TDMA, EDGE etc. At the protocol/standards level both schemes were interoperable internally, and both schemes were actually good examples of SOA implementations (that's something to think about another time). But they used different standards.

  • I'd wager that if you insisted on 100% compliance to any specific standard, you'd have to throw out 99.999% of the world's services!

    The fact that services (whether you are talking WS* or a generic definition of services) can be interoperable without being fully standards-compliant is one of the strengths of SOA.

  • I agree with the consensus that seems to be running rampant through this thread: that SOA is an architectural style, and the beauty of it is that it is not wed to any standards, let alone technology platform or language. Standards will keep evolving and changing (and sometime get abandoned) as the years go on; but SOA is more of a methodology and philosophy that is adaptable to any set of standards, be they community based or proprietary. Many folks associate SOA with Web services (SOAP, WS-*, etc.) only because Web services has been the least path of resistance to SOA.

  • I'm not sure of the ethics here so forgive me if I'm out of line responding to 'my own' question but I'd like to clarify a couple of things based on some of the comments made.

    My main point is that if SOA is simply an architectual style, it is absolutely nothing new. This point has been made before on a number contributions I have seen here and elsewhere. I have been involved in projects for many years where we wrote 'service routines' that were called from multiple places. Given that many of these were written in assembler in the 80s, we've had 'SOA' for over 20 years. I've never seen an answer that explains what is different to SOA if it is simply an architectural style and how it is implemented doesn't matter.

    I did not intend that 'standards' in the question related to my somewhat narrow view of what standards work. I did not intend that the only standards considered would be confined to my biases with regard to WSDL, SOAP, REST etc. There are many other standards out there so if people have a preferred set of standards that work for them, fine. If they work within a SOA, they are also providing something different to what we have had up until now in terms of interoperability.

    However, as another contributor here has said, the 'base' WS standards are the ones that are being used because they work well. I also believe we are suffering 'death by standards' to a certain degree. A lot of the next generation of standards which built on Web Services are so complicated that they are extremely difficult to use and thus do not gain the wide spread acceptance. SOAP, WSDL etc. are by no means perfect but they have gained an acceptance and have proven they are interoperable between many different platforms. IMHO, the interoperability offered by (any) standards is the key benefit of what we have today.

  • Well, I'm behind in my responses so the momentum on this question may have ebbed but I can't resist anyway. The original question was "how do we differentiate a SOA implementation using standards from a 'generic' SOA?"

    My knee-jerk reply was to say "the SOA build on standards is one that works" but I realized that wouldn't really add value to this discussion without further clarity. I like the core question here as it asks what makes a SOA implementation generic -vs- one that uses standards. Expanding on the discussion, what I think is at the core of this question is a related qustion -- at what point does a SOA become guided -vs- adhoc? A SOA implementation built on standards means that some architectural discipline went into the "how" aspect of how the SOA would be implemented and into managing the lifecycle of building out the SOA implementation through policies and governance. A "generic" SOA, IMO, happens when individuals and teams decide that SOA is the "thing" to be doing and just start implementing SOA-like solutions without this guidance.

    A guided, governed SOA will most likely be using standards that meet the architectural and interoperability goals of the organization and those standards may be any number of defacto or dejure standards that make sense to the organization, whether they be SOAP, WSDL, other WS*, REST or others. But the real value to me is the fact that the SOA is guided, has purpose, has individuals that are overseeing its consistency and the organization's ability to deliver solutions in accordance to a SOA goal and set of policies so that interoperability and easier integration get more and more achieveable over time even as the organization changes and expands.

    So, in essence, a SOA based on standards is a "SOA that works"

Add a Reply

Recently Commented On

Monthly Archives