Episode #2: “SOA & Web Service Technology”

Introduction

So, do you work with Oracle SOA Suite?, that’s great because we also do, every single day since a long time ago. As Oracle professionals, we’ve seen the SOA stack grow, change, incorporating new products and technology with each version, from 10g to 12c.

We’re Rolando Carrasco (Oracle ACE) and Arturo Viveros (Oracle ACE Associate), the SOA Myth Busters from Mexico, and as we go with this series we will put to the test a number of questions, myths and urban legends regarding both SOA & the Oracle SOA Platform in seek of finding out which myths are true and which are not.

SOA & Web Service Technology

It’s a secret to nobody that Service Oriented Architecture and Web Services go hand by hand. However, the relationship between these two is very often and very awfully misunderstood. Thus, there are plenty of myths and misconceptions surrounding this particular topic, which we will attempt to tackle and clarify within this episode.

Let’s take a look at some pretty common (and possibly wrong) statements regarding the relationship between these technologies:

  • SOA == Web Services Technology
  • I’m implementing Web Services, therefore I’m implementing SOA
  • There’s no other way to do SOA besides web services
  • In a Service Oriented Architecture, the more web services the better
  • Let’s expose everything as a web service, with the purpose of developing a service-oriented approach
  • Jumping into SOA will be easy because most of my proprietary software is capable of auto-generating “SOA-ready” web services
  • Virtualizing my services through an ESB, automatically upgrades my point-to-point integrations to a fully-fledged SOA.

The Myth

“A successful SOA with all of its benefits, can be achieved simply by investing thoroughly on the development, enhancement and proliferation of a web services platform.”

So why not start like we always do by providing a little context for the matter in hand:

Web Service Technology

Many organizations use multiple software systems for their own purposes. Different software systems often need to exchange data with each other, and a web service is an increasingly common method of communication that allows two software systems to exchange this data over the internet.

A very plain definition for the concept of “web service” would be the following:

“A web service is a method of communication between two electronic devices over a network.”

The W3C Web Services Architecture Working Group, has furthermore defined a Web Services Architecture, requiring a specific implementation of a “web service” in the following way:

   “…a web service has an interface described in a machine-process able format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP (Simple Object Access Protocol) messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards…”

The W3C also states:

We can identify two major classes of Web services:

  • REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of web resources through a set of stateless operations identified by a uniform contract.
  • SOAP Web services, in which the service may expose an arbitrary set of operations, which will be defined by a contract in the form of a WSDL-compliant XML

Service Oriented Architecture

It is well known that the term “service-oriented” has existed for quite a long time. In fact, it has been used in several contexts and for different purposes. One constant though, is that it will always attempt to provide a solution for achieving separation of concerns. The idea is that the logic required to solve a large problem can be designed, implemented and managed in a much better way if it is decomposed into a collection of smaller, interacting pieces.

This is a “divide and conquer” kind of approach, in which each one of these pieces should be prepared to address a particular concern or a specific part of the problem, not unlike other recent technological paradigms such as: OOP, AOP, etc.

What really distinguishes SOA is the way in which it goes about achieving the aforementioned separation, which would be by applying, to a meaningful extent, an appropriate combination of the following service-orientation principles:

  • Reusability
  • Standardized Service Contract
  • Loose Coupling
  • Abstraction
  • Composability
  • Autonomy
  • Statelessness
  • Discoverability

In essence, SOA is a form of technology architecture that adheres to the principles of service-orientation. When realized successfully, SOA should harness the potential to support and promote these principles throughout the business process and automation domains of an enterprise.

*If you want a really thorough explanation about the meaning of SOA and Service-Orientation, we strongly recommend the following site:

http://www.whatissoa.com

Web Services and Point-to-Point Integration

So now that we’ve left the customary introductions and pleasantries behind, let’s talk about some real-life scenarios in which the kind of technological elements we’ve just described are put in use.

We’ll start with a very common pattern, the classic point-to-point integration achieved via web service technology:

Point-to-point is a fairly simple integration model. It is normally used when a request-response pattern is needed between a single consumer and provider (that is, a 1:1 relationship). As an example, a home-made application needs to retrieve client information from a CRM system. In this model, the provider exposes a web service interface to which the consumer will make its request. ep2_p2pTraditional point-to-point integration

So, would it be feasible for an organization to achieve SOA by just “piling it on” with this approach?, what happens if we keep generating integrations by hanging web service interfaces on each and every one of our systems and applications? Maybe we can even throw into the mix an agile methodology, so the services can be developed and released at an increased rate.

While adequate for simple integration, this model can quickly become unmanageable for larger integration requirements. For example, assume that five different systems have to be integrated. This means that the total number of connections can be up to 20!! (A bi-directional connection counts as two connections) and so on.

Another drawback of this model is that it’s fairly fragile. By its nature, point-to-point integration is used for synchronous communications. If the receiver is down, the entire system can fail (or at the very least, hang) because of the tight coupling between the sender and the receiver.

ep2_spagHowever exaggerated an architecture like the one in the image above may seem, it’s not entirely unheard of though. It does illustrate how quickly this integration model can blow up in an organization’s face, and it has been a common result for some of the pioneer SOA projects which mostly sputtered and failed.

Amazingly, in the present time there are still companies, even some very big ones that still go down this way. In fact, since it has become incredibly easy to develop web services due to the enhanced auto-generation capabilities wielded by most products and tools, it can be very compelling for a business to achieve integration with just a few clicks.

Again, this is not a problem with “vanilla” integrations that are expected to remain simple over time, but it doesn’t bode well with Service Oriented Architecture since auto-generated services rarely comply with any of the eight principles mentioned before.

Web Services and the ESB Design Pattern

As we mentioned in our first episode, an ESB usually has a set of inherent capabilities that can make it potentially a great cornerstone for a service-orientation initiative.

ep2_esbHowever, there is a common notion in the industry that just by virtualizing services (which usually pertain to point-to-point integrations) through an ESB, an organization will be achieving a de-facto Service Oriented Architecture along with most of its benefits.

This notion couldn’t be more wrong, and in order to understand why, let’s review some of the benefits we would be expecting from SOA first:

  • Increased Intrinsic Interoperability
  • Increased Business and Technology Alignment
  • Increased ROI
  • Increased Organizational Agility
  • Reduced Vendor Lock-In
  • Reduced IT Burden

If the services we are virtualizing are not aligned with the service-orientation principles, then they will probably won’t be effective composition members, it will be very hard for them to keep evolving and will also probably remain tightly coupled with proprietary technology. In order to achieve standardization, we will have to rely heavily on the transformation technology provided by the ESB, which will only increase complexity, maintenance costs and performance-related challenges.

ep2_esb2The bottom-line here is that as powerful as a particular ESB may be, the product per se is not enough to guarantee a successful service-oriented implementation.

Even more, we all know that with SOA the actual acronym has become a multi-purpose buzzword, especially when it forms part of a specific product’s label (e.g. Oracle SOA Suite, TIBCO SOA Development Platform, Software AG SOA Suite, etc.). Nevertheless, we must understand that what we have in our hands is something that was created and will work in support of an architecture based on service-orientation principles, not a panache or a “magic box” that will automatically and seamlessly produce the technological solution we are looking for.

Web Services and Industrial SOA

In our current time, service-orientation has evolved into a much more robust paradigm, which may be labeled by different authors as Industrial / Contemporary / Modern SOA.

Industry demands, as well as new tendencies and trends have already begun to influence the way in which we must approach an Integration / SOA project. Some examples of this influencing factors are:

  • Cloud computing (SaaS/PaaS models, iPaaS, Cloud integration, hybrid architectures, etc.)
  • Mobile
  • E-Business
  • Web 2.0
  • International Standards and Regulations (e.g. eTOM, PCI, FIX, HL7/HIPAA etc.)
  • Internet of Things

Web services in a SOA context, more than ever, are intended to be independent building blocks with a number of unique characteristics that allow them to participate effectively as part of a service-oriented architecture. ep2_comp

As depicted in the image above, it is through service composition that we can successfully reuse and orchestrate the functionalities showcased by a service inventory, in order to efficiently automate business processes.

There’s another important element to consider when developing web services in an Industrial SOA context. For all the reasons stated beforehand, it’s pretty clear that SOA should strongly promote reuse, interoperability and composability. SOA services then, must be designed with generic processing functionality driven by various types of meta-information the service locates in the header blocks of the messages it receives.

The use of header blocks in compliance with the WS-* standards, provides the Web services framework with an extensible and elegant way to implement a set of message-based functionalities through the use of header blocks. Examples of the latter include:

  • Dynamic routing
  • Addressing
  • Message-level security measures
  • Reliability rules related to the delivery of the message
  • Context and transaction management information
  • Correlation

REST Services and Industrial SOA

REST (i.e., RESTful services) are pretty straightforward; basically, they adhere to a set of constraints and architectural principles that include the following:

  • RESTful services are stateless, meaning that each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server
  • RESTful services have a uniform interface. This constraint is usually taken to mean that the only allowed operations are the HTTP operations: GET, POST, PUT, and DELETE.
  • REST-based architectures are built from resources (pieces of information) that are uniquely identified by URIs. For example, in a RESTful purchasing system, each purchase order has a unique URI.
  • REST components manipulate resources by exchanging representations of the resources. For example, a purchase order resource can be represented either by an XML document or a JSON string. Within a RESTful purchasing system, a purchase order might be updated by posting the resource to a pre-defined URI.

So, why and when should we use this kind of service architecture in conjunction with service-orientation?

First of all we must make it very clear that there are really no conflicts between both REST and service-oriented computing goals:

  • Service oriented computing goals are strategic and business-centric.
  • REST goals are technology-centric and can help achieve either strategic or tactical business goals.
  • While not all REST design goals are relevant to each service-oriented computing goal, most REST design goals are directly supportive of service-oriented computing goals.

In the other hand, RESTful services present a simple, modern and standardized, yet lightweight alternative to the development and implementation of SOA components, especially when technologies such as Cloud, Social and Mobile become involved.

Conclusion

So let’s try to answer the questions we asked ourselves at the beginning of this article, while running through the conclusions to it:

  • Web Service Technology doesn’t equal SOA; however, the web services platform is a huge cornerstone for the realization of the principles which define modern service-orientation.
  • Using web services (and RESTful services) to build a Service Oriented Architecture is a great idea providing organizations don’t lose focus on those principles and the benefits they are trying to attain.
  • Regarding service-orientation, proprietary web service technologies and service auto-generation can really set organizations back and deviate them from the most relevant objectives pursued by this approach (interoperability, composability, standardization).
  • An ESB bodes very well with SOA as a design pattern, and can be a very powerful tool in the sense of enhancing and further fostering the service-oriented capabilities of web services. It does not work however as a substitute for the absence of service-orientation principles in the virtualized components. Organizations that choose to obviate this matter while pursuing a SOA initiative can be in for a very huge disappointment.
  • In contemporary SOA, reuse, composition, re-composition and business process orchestration should be the ultimate goal of a service inventory, as opposed to sheer quantity of web service interfaces.

With all of these in mind, the myth we set out to tackle:

“A successful SOA with all of its benefits, can be achieved simply by investing thoroughly on the development, enhancement and proliferation of a web services platform.”

…has been thoroughly demystified, so we might as well provide a more suitable statement:

“A successful SOA must adhere to the principles of service-orientation in order to fulfill its promise. When realized through the web services technology platform, we must aim for a service inventory which can establish the potential to support and promote these principles through reuse, composition and business process automation”

We certainly hope that this body of work has been interesting, useful and enjoyable for you appreciated reader. Let’s meet again in our next episode!!

The SOA Myth Busters

Advertisements

One comment on “Episode #2: “SOA & Web Service Technology”

  1. Pingback: soa mythbusters | SOA Community Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s