A common mistake when people talk about SOA is to lump it together with web services. Some people think that SOA is web services because they get lost in the discussion when acronyms like SOAP, UDDI and WSDL are thrown around. Let’s not even mention WS-AtomicTransaction, WS-BusinessActivity, WS-Policy, WS-ReliableMessaging… the list goes on.  In fact there are so many details around those standards that they have become known as WS-* for short. 

SOA is not about web services: SOA is about how to get to your application architecture on a level so that businesses can better adopt new functionality without disrupting existing investments.

A Little Background

Behind the curtains, part of SOA architecture is connectivity.  I like to define two types of style for the sake of simplicity: either you connect real-time (synchronous) or by events (asynchronous).

Let me give you examples of these in action. If you are buying your favorite MP3 player online and, at the moment of ordering, you receive the right price and the right availability then that is real-time. Once you click “order” and that order is processed an event occurs.  The event generates a message that the shipping department must respond to, but it doesn’t need to be in real time.  That order is then handed off to the shipping department and put into their work queue. 

As you have read from the previous posts, Infor Open SOA supports the event-driven style and enables solutions to remain independent of each other, which in turn promotes flexibility and scalability. Nevertheless there are cases, like the one I just described, where a real-time style is required.

Getting to the point…

Since the advent of SOA, the only technology that has been positioned for the real-time style is web services using (here it goes....) SOAP and WSDL.

• What’s SOAP? It is a technology to “envelope” the message you send or receive.
• What’s WSDL? It defines the structure of the message you send or receive.

Think about sending a letter to your friend: the envelope where you put the letter is SOAP while WSDL defines how the content of the letter inside is structured.

The current incarnation of web services has failed to deliver on the hype.  Although web services are widely used, there are too many variations on the standard. This makes it difficult to reuse services without adding additional development. 

So, is there an alternative?

Yes!  REST (Representational State Transfer) offers an alternative to build real-time connectivity in a much simpler way. Although the acronym may sound difficult, REST uses the World Wide Web style that everybody knows to access information. Instead to “enveloping” data and constructing difficult and complex data requests, REST leverages a URL to access data.

For example, if your company offers a catalog of MP3’s, the way you would access from a program is like you do in your browser: http://myco/catalog/mp3. If you would like to access a specific mp3 and its price, the link would be looking like: http://myco/mp3/price/modelXYZ. REST can return different formats like XML and HTML, just like the web does today.

Now I‘m not advocating that you throw out your web services development. As the American’s say, “if it ain’t broke, don’t fix it.”  However, in the future, there is a better option.  REST is simple and open to everybody, and that’s what made the WWW successful.  This is certainly a style to consider when you architect real-time type of connectivity. In a future blog, we will touch base how Infor Open SOA leverages REST in its architecture.

Posted by Massimo Capoccia, Director Product Management, Technology