I am frequently asked certain questions about service-oriented architecture (SOA). Within the System i world, SOA is at an early adoption stage; companies are still exploring this paradigm. I hope this article will provide answers as to why you might consider SOA in your System i.

Is SOA Hype or Reality?

It is a little of both. The current wave of SOA is reminiscent of 1994, when ERP three-tiered architecture was the frenzy. Vendors today are putting some sort of SOA in their taglines, but I think it's mostly for press. That's where the hype comes in. Many analysts' projections try to define what tool is necessary for SOA today. The last three years have proven that they missed who will have SOA at this point. One of the biggest misconceptions is that it is easy to do.

The reality part of SOA is that it encompasses a lot of good architectural practices, such as layering, loose coupling, and separations of concerns. SOA really is an architectural style that can be applied to any organization. Customers cannot just buy SOA; it is more a combination of buy and build. Whether you are going to buy a product or use an open-source product, you have to build the architecture. If you don't have the architecture in place, there is no product out of the box that will give you SOA today.

Here's another point. Numerous innovative companies are already using Web services as part of their SOA paradigm to execute real business processes with partners and deliver value to customers. These pioneering companies are gaining valuable experience, allowing them to create a new business architecture that will position them for long-term growth.

Who Are the Early Adopters of SOA?

Companies that use Web services today for real business are at the early stages of SOA. With IT budgets shrinking, deciding where in the organization to start SOA is a challenge for managers. Which companies are thinking of going with SOA today? They are typically innovative market leaders that want to gain experience with a more loosely coupled architecture that has the promise of quickly delivering measurable cost reductions. They are companies that integrate to multiple partners or customers in heterogeneous systems.

In banking, this means companies like Bank of America, Wachovia, Wells Fargo, Charles Schwab, Merrill Lynch, Fidelity Investments, ABN Amro, Barclays, Credit Suisse, Thompson Financial, and Thomas Weisel Partners. In insurance, it's companies like Blue Cross/Blue Shield, Mega Life, Storebrand Group, Hartford Insurance, and AAA. In manufacturing, you have Dell, Ford, and GM. In the travel industry, you have Budget Rent a Car, Avis, Sabre Holdings, and Orbitz. For the Internet, you have Amazon, eBay, Google, and Yahoo.

Most industries are relatively data-intensive, and to cost-effectively meet their customers' needs requires them to collaborate with multiple parties. For example, banking consumes extensive data feeds and produces research reports that must be distributed to a wide variety of clients with specific individual needs. Similarly, as any traveling professional who rents cars or checks into hotels knows, travel requires detailed customer profiles and inventory data. Large economic benefits, to customer and company alike, are to be gained from being able to key in data only once and then have it move across service providers, with automatic notification of cancelled or delayed arrivals so that car/hotel inventory can be optimized. I had first-hand experience recently when I booked a flight with Orbitz; I got a call from Orbitz, announcing that my flight was delayed and that the terminal it was being routed to had changed. I am pretty sure that Orbitz married VOIP into its CRM SOA architecture.

How Do I Get Started Building SOA in My System i?

When building SOA, always strive to create loosely coupled services, with reuse in mind. These services must act as building blocks for your application; introduce them slowly enterprise-wide. The exercise of building the blocks allows you to add new building blocks (new business requirements) or replace old building blocks as your business changes.

When creating the service, always start small. If you plan to leverage your existing legacy (monolithic in nature) application, start by decoupling the application and defining your business services written within the application. When choosing what applications to start with, the best method is to consider the "low-hanging fruit" application that will give you the best ROI. Starting with a simple project will allow you to measure the ROI before making a large commitment. Plus, you will gain experience, thereby eliminating some headaches when you move to larger projects.

You probably have an existing prototype that is widely used within your application. If a project requires that an application be exposed, for example on the Web, and that this prototype be used as one of the building blocks, consider using a program wrapper (using WebSphere) to expose this prototype and register the WSDL in the UDDI to allow Java developers to use the System i prototype.

If you are starting from scratch in the System i, define your business essentials and requirements. Design your relational database based on the business imperatives; then, build small business services around your database.

The goal of SOA is to create building blocks for enterprise-wide usage in the future, but your initial goal is to build blocks to perform specific services that meet your business goals. Start by creating process flow to help understand how blocks work together or separately. The services done for each block must be identified within your process diagram. Do not repeat the business function used by one block into another block. Always keep reuse in mind. Once you've identified your building blocks and the way they fit together, make sure you have the ability to change blocks. Not all blocks will be identified in the beginning, but don't worry; you'll build more blocks as you identify the need for them. One of the common pitfalls I have seen is that developers tend to overcomplicate things. Do not over-engineer your process flow. Build as you grow. Build the business requirements first.

Whether you are building SOA from scratch or leveraging existing applications, you may be required to do research and proof of concepts (POC). Make sure your POC is in line with your business requirements, not focused on the technology. Remember to start small. Produce in phases, don't overcomplicate, and then deliver to get a quick win to show the value of SOA. Enabling technology comes as your SOA environment matures.

What Technology Do I Need to Get SOA Rolling and Leverage My Legacy Application?

Your legacy applications will be part of your SOA solution, since they are not going away anytime soon. SOA suggests that we expose various services based on business initiatives and requirements. Most of the services that will initially be exposed will be more internal than external. Once the services are identified, documented, and prioritized, the necessary technology to expose them can be determined.

I mentioned earlier that business services drive SOA, and as SOA matures, technology follows. There are three steps to follow to leverage your legacy application and roll it forward to SOA initially:

1. Implement a componentized business design—Look at your business as a set of processes within your legacy application. Many legacy RPG applications need to be modernized. System i has tools like Databorough's x-Analysis to accomplish this. (Editor's Note: A more complete list of modernization tools can be found in the MC Press Buyer's Guide.) RPG applications move easily to Model-View-Controller (MVC), making it easy to expose business processes as a service. If you don't have time to do MVC, you can use IBM's alternative, HATS, to buy time.
   
   The reuse of legacy assets is touted as an initial selling point of SOA. In reality, many legacy applications will require restructuring to be of much use. The real payoff comes from adopting a programming style that will make new services easy to reuse later.
2. Slowly expose elements of business processes as services—Leverage your existing ILE programs and service programs as providers of services. Slowly transition your ILE programs as consumers of services in the future. The key here is to develop existing programs as Web services. Use WebSphere Development Studio Client (WDSc) to provide Web services directly from the RPG application. System i programs can also consume Web services from RPG using APIs. The success of integrating your legacy assets is related to the difficulty of crafting adaptors. Luckily, WebSphere handles this with ease, allowing a straightforward integration.
3. Connect applications and services—There are many options in WebSphere (or BEA's WebLogic) for clients needing to connect to System i–created Web services. However, when other heterogeneous systems are considered, Java Message Service (JMS) would be used (e.g., WebSphere MQ or TIBCO RV). Larger customers will be more open to an Enterprise Service Bus (ESB). WebSphere ESB for i5/OS will be available first quarter of 2007. Other methods of calling RPG programs would be to use Program Call Markup Language (PCML) for Java or JEE Connector Architecture (JCA).

Please refer to the IBM System i Tools Innovation Program for reference to other Integrated Development Environment (IDE) tools available for the System i. Note: Most tools provided by ISVs require additional vendor licensing costs and vendor-proprietary codes, making it hard to fully embrace SOA.

Do I Need an Enterprise Service Bus (ESB)?

ESBs provide links between services within the company and beyond your business to connect to your trading partners. The ESB is the middle tier of the SOA infrastructure stack. It is the glue that binds the process orchestration to your services. An ESB is a message-based capability that facilitates interaction between distributed resources. An ESB is not required for SOA; however, it does increase the power and flexibility of SOA usage.

Business analysts predicted that ESBs would be the core to SOA. I suggest investigating further what an ESB can do for you and considering several factors before investing in one. An ESB implements SOA through middleware, through management of service interactions between consumers and providers. This layer helps connect and integrate IT infrastructures across many systems and locations.

So what does an ESB do for you?

• Identifies the messages and routes them accordingly
• Allows messages to flow across different transport protocols from consumer to provider and back
• Automatically transforms message formats
• Provides robust and secure program-to-program communications for all types of applications
• Uses Web services to enable integration of all types of function to match enterprise needs
• Provides business with capabilities to route processing as needed
• Manages message definition, format, and description easily

Are you still wondering whether you need an ESB for SOA? The following questions can help you determine whether you need one. If you answer "yes" to two or more of these questions, you might want to consider investigating an ESB within the next year or so.

• Do you plan to implement a large-scale SOA strategy?
• Does your value proposition require an accelerated market shift, affecting your ability to meet your business goals?
• Do you own several existing Web services that may not be presently enabled in the enterprise?
• Do you need to manage modular applications that are dynamic and in disparate systems?
• Is your IT budget increasing, and are new investments being considered?

Vendors have hijacked ESBs in order to hype up their product line. But this is not the silver bullet vendors are promising. Ongoing debate on the Web begs this question: Does middleware such as an ESB resolve a problem or just create a new layer of problems? Personally, I don't think ESBs have reached their full potential and maturity. An ESB allows you to address the service endpoints that you wish to invoke. To make this work, an ESB must map a logical address of the service to correspond to a "physical" address. Most likely, a registry (e.g., UDDI) is used to look up the physical address. Looking for the address each time a consumer accesses a service is costly, but if the ESB caches the physical addresses, the overhead will be low. The purpose of an ESB is to allow building flexibility in the infrastructure rather than implementing it in each service endpoint. An ESB must eliminate the consumer's need to deal with upgrades and load balancing between instances of specific services (e.g., the consumer invokes a service, not realizing that there may be many instances). It is uncertain that today's ESB delivers all these capabilities.

I believe the value of an ESB drops considerably unless it is the mediator for most of the service consumer/provider conversations. I used to work in a large financial institution that had high-volume, performance-critical applications. We had well-defined providers and did not need orchestration, transformation, or even routing. Companies like these do not want to incur the overhead or support of additional mediation tiers. In this case, an ESB is not well-suited. An ESB is a product that makes SOA manageable for companies that have many services. If your company has only a few services, there is no hurry to jump into the bus.

Why Is SOA Needed for my System i? Why Now?

SOA is not a new approach to be adopted by IT. In fact, this paradigm has been around for a decade. However, it is gaining popularity in the System i world because companies are increasing the functionality of their IT assets, and a bunch of newfound technologies have recently become available in System i.

One of the first things you need in order to build systems out of parts is a standard way to represent the parts. It becomes extremely difficult without the standards in place. SOA is not new. Over the past 15 years, companies attempted to come up with standards (e.g., CORBA and DCOM), but they never became global standards. Thanks to the Internet standards like HTML and HTTP, we are able to connect easily and rapidly. Organizations and industry leaders started thinking about how to use the technologies born from the Internet to link together disparate systems. Organizations came up with Web services standards. Web services use technologies like HTTP and XML to represent parts and to link together multiple systems. Starting in 2004, there was an initial adoption of Web services as the set of standards and baseline for SOA.

The three main industry organizations focused on establishing standards for Web Services are the Organization for the Advancement of Structured Information Standards (OASIS), the World Wide Web Consortium (W3C), and Web Services Interoperability (WS-I). They got the ball rolling to create standard taxonomy for SOA. IBM, BEA, SAP AG, Oracle, Iona Technologies, Sybase, and Xcalia all teamed up to get behind SOA programming models to make SOA real and easily adoptable. The available tools and enabling technologies from these vendors have matured in recent years.

SOA may not be for every shop running System i. SOA delivers significant benefit and cost savings for any organization, but one thing that is very important and always missed is that SOA requires discipline and enforcement of centralized governance (IT and business) to be successful. For some organizations, the cost of developing and enforcing policies maybe higher than the benefit realized—and therefore not a practical initiative.

What Are the Main Components of SOA?

A complete SOA solution will include the following:

• Providers—A provider (or producer) is an entity that offers a specific service or functionality.
• Consumers—A consumer is an entity that makes use of the service offered by the provider.
• Services—A service is an entity that performs a specific task when invoked.
• Contract—A contract (or interface) specifies the format in which information needs to be provided to the service to perform a specific task.
• Repository—A repository is the registry and includes the metadata—namely, the service, service contract, service address, and data/object model.

Can I Just Buy SOA?

With the popularity of SOA, it is bound to help sales of several vendor products. But it is a myth that SOA can be sold out of the box. SOA is something you build, carefully studying applications and planning services that can be reused across the enterprise. If it is sold out of a box, it's probably not reusable. Vendor products plus your company's set of design principles make up a successful SOA. The tools need to be supported with a set of practical examples before SOA can be successfully proven to customers.

What Issues Will I Face When Implementing SOA in System i?

There are challenges. The biggest would be resistance to change and skepticism. Certain cultures within business and IT are not agreeable to SOA. Too many people resist new approaches, simply because they are comfortable with the skills they have and don't want to learn anything new. Companies that wish to have any success in making consistent progress in SOA projects should identify not only the people who champion the cause of SOA, but also those who build roadblocks that halt the progress of something they see as threatening.

Another challenge would be duplication of effort. A disciplined process and organizational structure must ensure that existing services are monitored, reused, and not duplicated.

Another problem would be the lack of awareness of how to decouple legacy applications. I have written an article called "Does SOA Mean Save Our Assets?" that discusses in detail the complexities faced by System i organizations when integrating SOA. It addresses the effort and techniques required to decouple your legacy application. You can find that article in an upcoming issue of iTechnology Manager.

What Is My Cost Benefit of SOA?

There is cost associated with investing in SOA architecture. SOA is a hard sell to executive committees of any organization. I once told my CFO that if he gave me $1 million today to buy software, it would save us $5 million in three years. He said that if he didn't give me $1 million now, he just saved the company $1 million. Sound familiar?

SOA does not help reduce your cost now. SOA does help reduce future expenses related to application deployment by improving the flexibility, scalability, and reuse of functions in the overall business schema. SOA cost can be easily justified if you start with small projects and build incrementally. And since reuse is one of the best ways to save money, it becomes clear how SOA will eventually save money.

If the cost associated with SOA is to leverage your existing legacy applications, a shift in the current application building block methodology must be implemented first as part of your SOA strategy, and an investment in decoupling your existing monolithic applications must be included in your cost initially.

Understanding Is Key

All System i professionals need to begin to understand how SOA plays in our sandbox. SOA will become an open discussion sooner than anyone can imagine. Each company will build its own SOA strategy. I hope this article serves as a catalyst to System i professionals and inspires interest in SOA.

For more information about what SOA can do for you, refer to this case study: "SOA in an Age of Legacy Integration."

Alex Nubla works as the Enterprise Architect for Health Net. He used to write technical articles for Powerbuilder magazine, Midrange Computing magazine, and iSeries News magazine (even way back in News 3/x days). Alex lives in Southern California now, after relocating from Charlotte, North Carolina, where he worked for Bank of America as the V.P. in charge of technical support for System i. 
 
Alex hasn't written articles for the past nine years because of the high demand on his consulting work. However, he has written numerous utilities and always makes them available for free in the System i community.
 
Alex has always been a great supporter of the System i. He has butted heads with other industry folks who refer to the System i as old technology. He says, "I don't want to be portrayed as an old bigot who loves System i, but the truth is System i is here to stay. And please, don't call it a legacy system."

Alex Nubla is a subject matter expert specializing in Service-Oriented Architecture (SOA). He has served in a variety of technical and business roles across a broad range of industries, including banking, finance, supply chain, and healthcare to name a few. Alex' current post is as a SOA Strategic Lead and a Director for Health Net Inc.  Email. This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails