Service-oriented architecture (SOA)... What's this? One more new marketing concept invented by smart ISVs? A new IT fad for companies that have an R&D department and time to spend in investigations? And if this really works, does it work for System i shops like yours? What does it mean to your legacy applications developed in RPG and COBOL? And what about your packaged applications? Are all these applications SOA-compliant? Is your System i "SOA-ready"?

This article, which will guide you in developing a plan for SOA adoption, gives special consideration to constraints under which organizations with a substantial commitment in System i technologies must work to protect and extend their legacy investments.

SOA: Another Definition?

SOA isn't really a new design pattern. It's nothing more than a certain type of architecture. In this architecture's topology, all the functionalities are provided as "services." In this way, you have an improvement in deployment flexibility and reusability never achieved at this level before.

Let's take the management of your spool files as an example of a service. You are usually using the WRKSPLF command. Through this command, you can perform any function on a spool file: send, modify, delete, etc. You can also use a direct command, like DLTSPLF. This command can be called from anywhere, through a remote command. You can see this as a "service."

So the service encapsulates the business logic that makes up the service. Theoretically, the service can be created with any language that you run on the target platform where you intend to deploy the service.

A service never runs without a clear interface definition. This interface describes not only the parameters you will send and receive (like an API), but also the way you will access this service. This "contract" between programs that defines how to access the service could use XML, SOAP, messaging middleware, or shared memory to pass data. When it uses SOAP to define the data and WSDL to define the interaction, it is called a "Web service." This "self-contained" service executes a specific task:

• Generic task: user authentication, messaging, etc.
• Business tasks: get customer information, validate credit card, create an order, etc.

The service is self-contained because changing a service should not impact other services. Therefore, these services are "loosely coupled."

What About the Architecture in SOA?

Software architecture defines how the components of an application are organized. You can think of it as a "blueprint," defining how applications will service both current and future needs, what components will be built and implemented, and which parts of an application relate and intercommunicate.

You can also think of an architecture as a plan that manages how an organization meets its IT objectives. This is particularly true when you adopt a vendor-provided application architecture.

Certain principles make SOA different from other architectures:

• Componentization—You will "cut" your existing application into a catalog of autonomous services with standard interfaces.
• Interoperability—SOA is more than a collection of services. Interoperability is one of the most important principles that SOA offers and is achieved by the use of standards-based technologies, unlike previous generations of proprietary EAI middleware.
• Reusability—This is especially important to System i companies. Building an SOA does not mean starting from scratch. SOA provides an interesting way for modernizing legacy applications by "extending" their capabilities across the i5/OS borders through the entire infrastructure. Even a .NET developer can use System i business services by encapsulating RPG code and exposing the service through a standard callable interface.
• Modularity—One of the first things that you learn when you start to develop is the modularity of your application's code. You will gain great flexibility when creating business processes.
• Agility—Adopting an SOA will help your software infrastructure react to business changes in a more efficient way.

SOA in a System i World

Legacy applications and packages are common in our information system. And one of the main characteristics of our world is that our infrastructure is based on large, monolithic applications that are often hermetic to the outside world.

That is why implementing an SOA is a journey.

SOA and Packaged Applications

A number of vendors have joined the SOA initiative. That's a very good and important thing because it is key to SOA's evolution. Software vendors can now propose an easy integration of their bricks into their customers' infrastructure.

For example, say your application provider brings you new functionality for creating new customers. If the packaged application provides this functionality as a service, it will be easy to integrate this function into your existing system. Your end-user may then key in the data once and simultaneously feed many applications.

Rather than buying a new packaged application, you are now buying new functionalities and new services from different vendors. And because they are standards-based, these services are interoperable.

It is your responsibility to check before buying that the service is really SOA-compliant and, for example, can easily be called from an external source. Many vendors already take this road (usually by implementing an API).

SOA and In-House Development

In the System i world, a number of critical business applications are still developed and maintained internally. Most of you have thought about "modernizing" these applications. SOA is one direction you may be thinking about. Thinking about separating your code and the management of the man/machine interface with the rest of the code is one example.

To achieve an SOA-compliant modernization of your information system, you will need an SOA-compliant set of development tools.

From System i to SOA

How do we go from our System i environment toward adopting an SOA?

I expect your system looks like that shown in Figure 1:

Figure 1: Today's System i will become the System i of the future. (Click images to enlarge.)

If you divide the system into the presentation layer, the application or the business logic layer, and the database layer, you are probably running some 5250 green-screen applications, the programs are procedural 3GL type written in RPG or COBOL, and you are using DB2 as the database.

If we map that over into the future, layer by layer, we can see the targets are Windows graphical user interfaces and rich- and Web-client types of technologies, which can support new or different device types (Smartphone, PDA, etc.). We also need to restructure that 3GL procedural code to create more of a component architecture, where we have business objects, with properties, events, and methods. We need to externalize the interfaces so we can call and invoke these components from other applications and systems.

More and more, people want to use different types of database technologies. Perhaps you want to deploy a Microsoft SQL Server alongside DB2 and also want to open up your DB2 database to other kinds of consumers. So where today some RPG programs actually access DB2, perhaps tomorrow you will have a Web site built using Microsoft .NET or you might deploy a new packaged application running on a J2EE application server. And you'll want all these systems to better access the existing DB2 data. To do so, you must provide access in a controlled way. With a data services layer that sits above the actual database technology itself, you can implement a consistent set of rules (edits, checks, etc.) such that every application or system that needs access to the database does so via this single, coordinated layer.

And you certainly want to be able to support something like Web services for standard interoperability. That will require an interoperability layer that runs alongside the new application architecture so everything you create can both publish and consume Web services.

To move toward an SOA architecture, we need to address three technology categories: a visual framework, a meta-data repository and application server, and a data services layer.

Visual Framework

A visual framework is very good place to start with modernizing your application, and it provides valuable assistance in your adoption of SOA.

The first benefit you gain is that a new visual framework insulates users from change. A 5250 terminal presentation generated from an RPG or a COBOL application is a coupled relationship. Changes made in the program are immediately visible and apparent to the users. To systematically reengineer that application logic, it is important to have a framework in place that provides users with a consistent experience, regardless of any reengineering at the back-end.

This framework also enables you to create composite applications. You can combine 5250 programs, perform DB2 queries, access Microsoft SQL Server, call Web services, etc. — and all in a single, composite view to the user.

Figure 2: Here's an example of your visual framework.

A visual framework also gives you flexibility for deploying the client. Rather than having one kind of presentation type (today 5250, refaced, or screen-scraped 5250), you will be able to generate a Windows, Web, or .NET client, depending on the needs or preferences of the user community.

Also, the new framework allows you to implement some new business processes and workflow. So you can focus on the user's productivity, eliminating redundant steps, strings, or keystrokes by using software automation to facilitate the execution flow of a business process. This allows you to selectively rewrite legacy functions and to add new functionalities. The users get a new presentation, a new workflow, and an enriched interface, and you can now add capabilities that were not practical in the legacy environment.

Meta Data Application Server

A primary function of a meta data application server is to maintain a meta data repository in which you have a library of built-in functions (common functions and those shared between similar business applications) and intellectual property (knowledge that makes your systems and processes unique to the way your organization works).

Keep in mind some fundamentals of a meta-data repository:

• The meta-data repository maintains all data definitions and rules. Rather than embedding the same rules in multiple programs (generating a maintenance nightmare), these are maintained centrally inside the repository.
• It is important to separate the business logic from the user interface. User interfaces are the fastest-moving part of the technology stack today, and the only way to cope with this pace of change is to achieve complete separation: no dependencies or tight coupling.
• Component-based development allows reusability of these components by providing a practical and positive environment where developers share code.
• Platform portability may be achieved by enabling any application to be deployed on a technology set that's free of client/server or database restriction.
• Interoperability should be built into all new applications by default. Start by assuming that the services an application provides will eventually be published. And remember that any application you build now may also need to consume other services later.

Data Services Layer

As Figure 3 shows, a data services layer is a single access layer for all data. Its purpose is to abstract format, location, and conventions. None of that knowledge needs to be hardwired into the programs that need to access these databases.

Figure 3: A data services layer is a single access layer for all data.

The data dictionary is held in the repository, not coded in individual endpoints. From this repository, you generate the individual gateway for any program or system on the network that wishes to access the database.

A data services layer offers multiple benefits:

• A single, standardized way to access all data
• Reusable parts
• Fast and simple deployment of new solutions
• Ability to protect data and rules

I'm on System i. Can I Play SOA?

In terms of SOA strategy options, I believe there are three levels of SOA:

First level: Some System i shops in the SMB market will never need the full-blown SOA approach. They do need certain benefits, like a modernized front-end when leaving the code as is. Just by using new tools, new skills, and best practices, they will be able to achieve that.

Second level: For others, SOA means interoperability. By embracing Web services as an open-standards, lightweight technology stack, they can achieve the benefits of interoperability.

Third level: And yet others will need to re-architect their systems for a variety of reasons:

• Inflexible architecture
• Poorly structured system
• A lack of skills within the organization
• A system in maintenance mode
• High-risk system to modify
• Missing functionalities because business has changed radically from the time the system was built

So the answer is yes; you can play SOA. The System i is very capable of being a peer participant in a services-oriented architecture. By using the right tools and technologies, there is nothing you cannot do on System i.

The real secret is to understand and anticipate where the benefits are; use SOA as a big picture, multi-year journey; and deliver incrementally to make service orientation more of a design concept than a big-bang approach.

Dominique Thomas is country manager for France at LANSA and has extensive experience in software integration and grid computing. You may reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..