Lesson number one: It's an architectural style, not a technology. Here's what else you'll need to know.
Every vendor has a service-oriented architecture (SOA) story; they just might not realize it yet, partly because the SOA terminology can be confusing to the uninitiated.
For example, when most people hear the term SOA, they automatically think Web services. There is a lot more to SOA than Web services, however. In this article, I give you an introduction to the IBM approach to the SOA architecture.
The SOA Recipe
First of all, SOA is an architectural style, not a technology. You implement an SOA architecture using technology, but too many people get lost looking for some product or technology right off the bat when SOA is primarily about a thought process. Truthfully, SOA could have been more aptly named ‘Save Our Architecture’ because its benefit is a free flow of business process data, both vertically and horizontally, from the enterprise to your supply chain and throughout your value net.
Start with some services…
To understand the SOA framework, you need to start at its atomic layer, a service. A service is really just part of a business process, again, not technology here. If you’re an IT savvy professional, this initial step may not come naturally to you, so I recommend you start by thinking about what your business does on a day-to-day basis. Every business has an objective.
For example, a financial company’s objective is to make money through a product family – one of those family members may be debt instruments. Finding ways to get you to spend money you don’t have is a key revenue instrument for financial firms and this is where debt instruments come in. Your typical financial firm offers a myriad of products, such as mortgages, that are tied to this fundamental business model. People take out a mortgage to borrow money that they don’t have to buy an asset, typically a house. A house is a fixed asset, which is typically recognized as a good thing for individual wealth creation. Mortgages have different life spans and amortization schedules, and come with interest rates that are usually within one to three points of the prime rate.
Credit cards are another debt instrument that financial companies use to generate wealth. They come with fancy monikers (like platinum, gold, and so on) and awards (travel miles, catalog merchandise points, and more), but they all have one thing in common: they have very high premiums over the prime lending rate and, if you don’t pay them on time, generate lots of revenue for financial companies, and usually lots of headaches for you.
So let’s get back to the service part of SOA. Think about what this company does on a day-to-day basis to support its business objective. Think of that as its high-level service, and break that up into the processes that underpin that operation. This exercise yields repeatable business tasks or components, called low level-services. An example of a service is a credit card application.
When you apply for a credit card over the Internet, you set a process in motion. You fill out some sort of Web form and submit it. That Web form typically ‘spits’ out XML to a backend process. Behind the scenes, a number of low-level services are fed the information from the XML and invoked. In this example, it’s likely a credit check, and if successful, it’s followed by a new account creation service. More advanced process modeling would include the entire end-to-end workflow. A simplified example is shown below:
You can see the various services in this previous example – remember, I’ve still not mentioned any kind of technology, or vendor, for that matter. I have no idea what technology is used to match the credit limit to the income request. I have no idea what data server is used to hold the information that can be used to determine if the applicant has good credit or not, or what mining algorithm is used to figure out the credit score, or what operating system these services are implemented on. The preceding figure just illustrates a bunch of repeatable business tasks.
A dash of service orientation….
The next step in understanding SOA is service orientation, which is a way of integrating your business as linked services. More importantly, service orientation is about the outcomes of those linked services. Again, I’ve still not mentioned any type of technology yet – it’s still a thought process.
Imagine building blocks of services that support your business objective. Some of the services that could be associated with my credit card application example are shown below:
The service that processes a credit check could invoke some internal mining algorithms in a local database, but in all likelihood is fulfilled by a company that manages credit ratings (such as Experian). Another service could get an applicant’s details from a relational local database, which could be used as input, or as a complement. The service that processes a credit check could invoke some internal mining algorithms in a local database, but in all likelihood is fulfilled by a company that manages credit ratings (such as Experian). Another service could get an applicant’s details from a relational local database, which could be used as input, or as a complement, to the process credit scoring engine. Finally, another service could use the information from the previously mentioned services to calculate the interest discount rate on the debt instrument. Economic theory dictates that the interest rate is really a function of risk (which is a big part of what is fueling the Basel II accord). The output of this service would likely be a lower interest rate for credit card applicants with good credit scores, and a higher one for those without.
Finally…some technology
Now that you’ve got your repeatable business services defined in the context of the philosophy of their implementation and workflow, you’re ready for the SOA part. In fact, here’s where the technology starts to come into play. SOA is simply the IT architectural style that supports the service orientation thought process and makes it a reality. After all, the customer details have to exist in some database, and the discount calculation algorithm has to be written in some language (such as PMML), and the whole application has to be architected around some programming language (.NET, PHP, or Java, and so on).
So using different programming languages, data stores, and so on, the modeled business processes have their jobs to do. The whole point of SOA, as you will see via the composite application in the next section, is that the service requester (the one asking for the results of these business processes) should be agnostic to the underlying technologies that provide the service and support them (programming language, operating system, database, and so on).
The Information Management brand in the IBM portfolio provides a feature-rich and flexible foundation for SOA. (You’ve likely heard the ‘Information as a Service’ slogan around its set of core products. The Information Management brand provides all sorts of native IBM data servers and content repositories, but extends the reach of data integration with products such as WebSphere Information Integrator to reach virtually any data asset or artifact: databases such as Oracle, SQL Server, Teradata, Sybase, and so on; XML artifacts, Microsoft Excel spreadsheets; specialized life science research databases such as BLAST; WebSphere MQSeries message queues; Web content; heritage data stores such as ADABAS, IMS, IDMS, and many more.
All of the data sources mentioned in the previous paragraph can be accessed without regard to the underlying technologies. For example, using the SQL API in the DB2®family of products, you can access data that resides in Oracle and SQL Server databases. The fact that SQL Server has a MONEY data type while Oracle uses NUMBER is of no consequence to the application developer. The Information as a Service architecture abstracts these complexities and automatically compensates for them through data type conversion services, function compensation services, optimization services, and more. That cornerstone of SOA has been a philosophy of the Information Management brand for a long time – long before SOA was even called SOA. This heritage provides a rich set of technologies to build the optimal SOA solution for your business.
For example, many Visual Basic.NET developers understand how to write a database application using ADO.NET but they may not know how to interact with a WebSphere MQSeries message queue. The Information as a Service framework provides a foundation by which the queues look like tables, and functions are provided to read, read-destructively, or write to these ‘tables’.
The composite application: it’s what uses the SOA?
Composite applications are the active services that have been assembled and strung together to support the business objective. SOA helps make building and adjusting composite applications fast, easy, and flexible, and that’s the whole point. If you take into account the previous figures in this article, a composite application could be represented by these blocks being connected together to satisfy the end-to-end business objective, as shown below. (I’ve added some other services to this figure to illustrate the vertical and horizontal business integration capabilities of the SOA.)
In the preceding figure, you can follow the original three services I’ve detailed in this article. This horizontal flow ends with a service to ship the client a new credit card. However, there could be some other workflow that is triggered from this particular workflow and thus becomes part of the composite application. For example, if the client is approved for a credit card, he or she may be eligible for 15,000 bonus points, which can be used to purchase products from the merchandise reward catalog. This secondary workflow is handled again by services and includes getting a price, calculating the shipping quote, and saving the ‘shopping cart’ for future reference or updating inventories if the product is eventually purchased.
Again, in this example, all of these blocks can be instantiated by different operating systems, programming languages, databases, repositories – the composite application just calls on the business processes it needs to complete the work.
So what about the technology?
For the most part, this article hasn’t discussed specific technologies. Yes, I did say that the IBM Information Management brand has a set of products in which the SOA philosophy is well engrained. But what components can you use to build an "SOA-ized" environment?
The IBM software portfolio provides a number of SOA-enabled and enhancing products through its various brands: Rational, Tivoli, Information Management, WebSphere, and Lotus. These software components allow you to model, assemble, deploy, and manage the entire SOA life cycle.
In addition to this, the IBM software portfolio allows you to superimpose governance controls on the life cycle, as shown below:
This SOA life cycle starts with the Model phase. In this phase, you gather requirements for designing your business processes. (The WebSphere and Rational brands can come in handy here.) Specifically, you understand the information assets that are available to you (and they may or may not all be yours) and link them to business context. In the Model phase, you’ll work with information metadata, develop data and content models, map information to business processes, and more.
Once you’ve tuned and optimized your business processes, you assemble the services using technologies such as the DB2 Universal Database (DB2 UDB) data server, along with WebSphere Information Integrator, WebSphere MetaStage, or the WebSphere Information Server (among other products that you can use from this portfolio). Rational products can be used here as well.
Finally, you’ll also typically choose the deployment type of your SOA here in this phase. While you’re likely already aware of Web services as being a deployment type, others exist such as Enterprise JavaBeans, Java Messaging Services, or MQ services to power an Enterprise Service Bus (ESB), and more.
These assets are then deployed into a secure and integrated environment for integrating people, processes, and information. The SOA environment responds to service information requests in its repository, and products such as WebSphere Application Server can provide the runtime environment, with products from the Tivoli portfolio used to deliver service responses, load balance requests, enforce service policy, and more. Products such as DB2 UDB can provide the persistence layer of the data (and optionally the runtime environment via the componentized WebSphere Application Server that comes with DB2 UDB) in a highly scalable and reliable manner. While the SOA framework is running the business, you need to manage and monitor it to ensure performance, availability, and security, and to meet service levels. You can do this via a number of log and monitor services provided by various products in the IBM software portfolio.
Once the SOA architecture is deployed and running, clients manage and monitor it so as to evolve the operational efficiencies of the business. Information gathered during the Manage phase is fed back into the life cycle for continuous process improvement – making it a closed loop feedback system.
Underpinning all of these life cycle stages is governance, which provides guidance and oversight for the SOA project. This information allows IT to better align the infrastructure by defining and redefining information management rules and policies.
Wrapping it Up…
In this article, I've given you the main ingredients and steps to implementing an SOA architecture. The main thing that I want you to take away from this article is that SOA is primarily about a thought process. Using this thought process, you can deliver great benefits to your business. Those benefits include a more efficient and flexible IT infrastructure, which can, in turn, help you evolve into what IBM calls an On Demand business.
Paul C. Zikopoulos is an award-winning writer and speaker with the IBM Database Competitive Technologies team. He has more than ten years of experience with DB2 products and has written numerous magazine articles and books about it. Paul has co-authored the books: DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, and A DBA's Guide to Databases on Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE) and a DB2 Certified Solutions Expert (Business Intelligence and Database Administration). Currently he is writing a book on the Apache Derby/IBM Derby database. You can reach him at: [email protected].
