More from the Architect's Dictionary
By Jeff Davies-Oracle on Nov 17, 2008
Architect’s Dictionary #2
From my last blog entry that contained a section on the “Architect’s Dictionary” I received several email asking for more definitions. I have included threeof them here. I do not have them sorted alphabetically. Instead I present them in the order that they should be understood.
I touched on this in my last blog entry but I thought it was worth a full description. Since services are at the heart of SOA, a solid understanding of what a service is seems in order. There is a weird cloud of mysticism around the definition of a service. I hear people say things like “services aren’t just web services” or “you can write services using [EJB | CORBA | .NET | Tuxedo | etc]”. However, ask these experts to define the term “service” and they usually have a lot of difficulty doing so. Which brings us to a basic principle of any type of engineering: if you can’t define it, you sure as heck can’t build it.
Fortunately, services are not mystical or magical. They are dead simple. You know what a service is, even if you can’t articulate it succinctly. You know what a “service” is because you live and work with services every day. You get electrical service from your local utility company, internet service from your phone/cable company and you get food service every time you go into a restaurant.
For some reason, when people start talking about services in the software architecture world, things suddenly become more complicated than they need to be. Shun that complexity; embrace the simplicity that is at the core of services. Simply put, a service is when I (the service consumer) ask you (the service provider) to do some work on my behalf and you perform that work in the manner I expect and within the timeframe that I expect, without involving me in the work.
It’s just that simple. Let’s examine services that you commonly use today, and then we can take a look at how these principles translate into the world of enterprise architecture and SOA.
Imagine that you are in a restaurant and you tell the waiter that you want a cheeseburger with potato salad on the side and an iced tea for the drink. If the waiter returns with your food but gives you a steak instead of a hamburger, he has not met your expectations (i.e. the manner I expect). The same is true if the waiter delivers the meal that you ordered but it is cold or uncooked. Again, the service has failed because the result does not meet your expectations.
Similarly, if the waiter returns with you food, cooked just the way you ordered it, but it takes him 4 hours to return with t he food, he has again failed to meet your expectations with regard to the time frame. Now imagine that the waiter tells you “Sir, we can fulfill you order, but we need you to come back into the kitchen to cook the meat.” Once again, they cease to provide a service at that point. If you have to do the work, they aren’t providing a service, they are simply helping you do the work.
The same pattern works for electrical service from your local utility company. When I come home at night and turn on the light switch, I fully expect to see the lights come on. Similarly, when I order new electrical service for my new home or apartment, I set a date of delivery when I expect that service to become active. Usually unstated is my expectation that I expect the voltage to match whatever is commonly used in my country. If the service provider fails to meet any of these expectations, they have failed to deliver the service.
Services in SOA
I hope the two previous examples struck you as being obvious, they should be. We all know what a service is. All we need to do is apply our common sense definition of a “service” to SOA
Translation & Transformation
The terms “translation” and “transformation” are often used together, or interchangeably. While it is technically correct to understand their differences, using them both in the same sentence often strikes me as, “over kill”.
“Translation” is simply the process of converting the content from one for to another. For example, I can translate a sentence from English, “I am hungry”, into Spanish, “Yo tengo hambre”. In terms of XML, an example of translation is:
Can be translated into Spanish, using the Euro for the price.
Notice that the translation did not change for form of the information itself, only the content.
Transformation involves changing the structure of the information, without changing the content. Using our previous example under translation, we can see how transformation works:
Can be transformed into:
From this example you can see that we did not change the contents themselves (beyond adding a currency tag with its contents). We did change the form of the information though. The key thing to remember is that while translation and transformation are different, they almost always appear together when providing loose coupling between different information systems.
Location transparency is a fancy term for loosely coupling the service consumer from the service provider, with regard to the physical location of the service provider. You use location transparency every time you use the web. If you browse the URL http://www.oracle.com you are using a logical name to access the Oracle web site. Oracle maintains numerous web servers that are mapped to that logical name. You have no idea where the specific web server is (and you really don’t even want to know). On the web, it is common to find a DNS load balancer distributing requests amongst any number of backend servers that do the real work in fulfilling your web requests. Location transparency is a simple concept, yet a powerful tool when it comes to loosely coupling information systems. It is just as applicable in SOA as it is in any other architecture.
Enterprise Service Bus
There has been a lot of buzz over the last few years over the Enterprise Service Bus (ESB). Books have been published, as have articles, creating a lot of hype. It may seem as though the only tool you need for SOA is an ESB, or if you have an ESB, then you automatically have an SOA. As is usually the case with any type of hype, these assumptions simply are not true.
One of the problems with the term ESB is that it has so single definition, no agreed upon set of functionality. Different vendors sell “ESBs” with wildly varying functionality. This is completely unlike the J2EE application server market, where there is a well defined specification.
Here I will define what an ESB means to me (and largely to Oracle also, though I make no claim to speak for my own company). I will define the functionality that I expect from any product that claims the title of ESB and attempt to explain the benefits of these features.
Too often I hear people equate an ESB with messaging. “An ESB is really just a messaging engine” is one of the most common misconceptions I hear in the field. This is false on its face. If an ESB was only about messaging, then any messaging system or technology would claim to be an ESB (and some do make that claim). Most J2EE application servers provide JMS capabilities. Are these application servers ESBs? Of course they are not. Obviously, an ESB makes extensive use of a messaging engine, but messaging alone is not enough to claim to be an ESB.
An ESB is a tool that really has a single purpose in enterprise architecture, to provide a mediation layer between service consumers and service providers. Mediation itself is not a feature, but an architectural approach that provides numerous benefits when combined with important capabilities like translation, transformation and location transparency (see above). Here is my list of features that I think an ESB must have to meet today’s demands.
- Location Transparency
- Configuration based, not “coded”
- Conditional Routing
- Content-based Routing
- Synchronous & Asynchronous Invocation
- Monitoring, Reporting and Alerting
- Clustering for Failover, Scalability and High Availability
- Translation and Transformation
- Industry standards for connectivity and integration
The key areas where messaging alone usually falls short are:
By providing a flexible, configurable mediation layer between the service consumer and the service provider, and ESB is a key technology and is a critical component in achieving the promised agility of SOA.
Ask the Experts
For this installment, I have selected several short questions:
Q How do I integrate OSB with Cobol and RPG programs running on an AS/400?
A Check out the information at http://dev2dev.bea.com/pub/a/2007/04/alsb-ifiveos.html
Q What happens when I hot-deploy a change to an existing proxy service?
A Side by side deployment is, sort of, built in to OSB in that an old version of a proxy service self-deprecates when the last in-flight message is fully processed. If you update a proxy service and deploy it, the old service will not process any new messages but it will finish processing any in-flight messages until it’s done with them. As soon as the new service is deployed, all new incoming messages are processed by it, not by the old version. There’s nothing to configure, no knobs to turn or bells to ring. Its automagic (thanks to Steve Waterhouse for this answer).
Q How do I integrate OSB 10gR3 with Oracle BPEL engine?
A This is a very common question and full documentation can be found here: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/bpelpmtransport/
Until next time, keep your hands dirty and your code clean!