SOA answers SOS

Wiring up everyone across the enterprise, and even beyond it, is the only way to move information rapidly. This much is understood and accepted.

CIOs, therefore, are being forced to find new and cost-effective means of moving information. However, this goal has proved both time-consuming and expensive.

The trouble is, every couple of years a new idea surfaces, which promises to make it easy for enterprises to get their applications talking to each other. Worse, companies often find themselves locked in rigid, hard-to-modify processes.

“Most software applications have been like the black box. You could not figure out what was inside…you could not change anything,” says Tarek El Shahawy, technology solutions and sales consulting manager, Oracle Middle East.

“And while information needs have grown, the budgets of IT departments have not increased over the last few years leaving them with the daunting task of leveraging existing IT assets to create the new applications required to satisfy the increasing thirst for information,” adds Diyaa Zebian, general manager, Middle East and Egypt, eSolutions BEA.

Service-oriented architecture (SOA) provides a neat way to build flexibility without stretching budgets too much.
A new application layer, called a service layer, pulls data from existing databases and applications and presents them in a user-friendly format. By making these applications available over networks such as the internet, SOA brings ubiquity to enterprise applications.||**||Varied formats|~|samerbody.jpg|~|Samer Karawi says SOA can make enterprises more agile.|~|SOA is a great tool to make enterprises more agile without having to abandon existing applications,” says Samer Karawi, marketing manager, enterprise and corporate communications, Hewlett-Packard Middle East.

Most enterprises have a vast number of information sources, including databases, text files, images, videos and directories.

The number of formats in which data is stored is as varied as the types of information. For an application to deal with the variety of information sources with their different means of furnishing information, new code must be written specifically for each source.

But these sources keep on evolving. Therefore, the application, too, must be modified each time. The necessary information is not all stored in a single data store, such as a database, but is instead stored in individual silos from which each application must refer to.

Each silo has its own characteristics. Some of the silos are packaged applications, such as customer relationship management (CRM) or supply chain management systems; some are files in a file system containing text, images, and video; others are in some form of storage such as lightweight directory access protocol (LDAP) directories or databases.

But each of these silos provides its own storage mechanism, its own storage format, and its own storage access mechanism.

“In an attempt to bring some order to the sea of information chaos, many enterprises are turning to an SOA approach to integration,” says Zebian.

This architectural approach also allows the incorporation of services offered by external service providers to be included in applications.

As a result, enterprises are able to unlock key information
in a cost-effective manner while also having the flexibility required to evolve as business demands change.

Such applications are easier to modify too as they are not tightly hardwired into traditional, monolithic enterprise applications such as enterprise resource planning (ERP).

Instead, they are loosely coupled; meaning a client of a service is essentially independent of the service. Services are implemented in such a way that the requestor — or the client putting the request for the service — doesn’t have to know very much about the origin of the service or even how to use it.

The interface, which could be browser- or graphical user interface- (GUI-) based and is defined as per functional requirement, makes it easy for the user to use the service.
He does not need to know what language the service is coded in or what platform the service runs on.

Middleware that sits between enterprise applications and the service layer does the job of interfacing. Think of it as an adapter that you attach to the power plug of your notebook.
The adapter can take in different types of power plugs on one side and plug into different types of switches.

It is up to the service to determine what business function (or functions) to apply based on the content of the document. The technology underlying the SOA does the same; it’s just that the method is a bit more complex.
||**||The SOA method|~|zebianbody.jpg|~|Diyaa Zabiyan claims companies can squeeze more benefit from their IT structures.|~|Often, new applications need to be developed to make enterprise applications available as services. But what really is a service in the context of SOA?

Take the case of a bank loan. A consumer who is seeking a loan goes to the relevant web page of a bank and clicks on a button, for instance the “Apply for loan” button. It takes her to another page displayed as some sort of a form.

Details such as income and account number are asked for on this page. The consumer fills up the form and submits it. The facility to apply for a loan in this manner is a service.

Once the request for the loan is logged, someone in the bank needs to take a decision to either sanction the loan or reject the application.

For this, the bank employee needs to know if the details provided by the customer are correct. He also needs to track the financial behaviour of the applicant. There is a good chance that all this information resides in different applications.

Customer-related data might be lying in a CRM application, while transactional data may be housed in some database attached to the core banking application. SOA helps cull out the relevant information and presents it in a format that facilitates decision-making. This is another example of a service.

Output from several services can be combined to configure a service at another level. For instance, a service that gives a snapshot of a bank’s portfolio of loans for the senior management can be set up aggregating output from the services that help various managers across the bank decide on loans.

In a way, SOA can be thought of as an approach that connects applications so that they can communicate with each other.
||**||Winning factors|~|buyukbody.jpg|~|Cuneyt Buyukbezci points to SOA’s flexibility.|~|But SOA is not a new idea.
Distributed Component Object Model (DCOM) or Object Request Brokers (ORBs) based on the CORBA specification attempted to do the same.

Each technology vendor’s DCOM was unique and, therefore, did not work with applications from other vendors.

Although a good idea, DCOM was doomed by lack of standards and interoperability. It failed to address companies’ need for flexibility.

SOA has two big factors going for it. One, the rapidly changing business environment makes flexibility a must. It is no longer about liberating a few managers from the clutches of IT-led processes.

Flexibility is now at the heart of a responsive, adaptive, “whatever-have-you” enterprise.
As Cuneyt Buyukbezci, software practice delivery manager, clients solutions, Sun Microsystems Southern and Eastern
Europe, Middle East and Africa, puts it: “Companies do not want to be locked in to a vendor. They are looking for agility and re-use.”

Another factor would be the emergence of standards such as Extensible Markup Language (XML), which is finally making interoperability between different vendors’ applications a reality.

A manifestation of this is a suite of web services built using XML that makes communication with clients possible through a set of standard protocols and technologies.

In fact, standards are what make SOA an approach with real, tangible benefits. Rival companies have come together to formulate standards, perhaps for the first time since software took shape as an industry in itself in the late 1980s.

These standards which, when fully co-opted into software platforms and products, will make different applications work in tandem. All that will be needed are “inter-connectors” that can be plugged in pretty much like the adapter plug.

“Oracle has some 250-odd inter-connectors. These are out-of-the-box tools based on XML standards,” claims Shahawy.
He cites another big advantage of this approach. “Earlier, whenever some changes have to be made, the application had to be written afresh. Now, using a GUI, modifications can be made to the application itself,” he says.

Some of this is already possible. The rest is on the roadmap. But the industry still has quite a bit of a distance to travel before it gets anywhere near that. Companies, too, have many legacy applications for which inter-connectors might not be available.

Yet, SOA is a powerful concept. It allows companies to do what’s most important to them — create solutions when they need them.

The fact that these solutions — or services — can be modified easily adds to the lure. Being browser-based or GUI-based, they are easier on the users. Many of the components that go into the making of the services are reusable. Essentially, adding new services gets easier and easier.

There is some debate, however, as to how a company should go about deploying SOA.
A white paper by IBM argues for enterprise-wide deployment. But in reality, the idea is being tested out in limited ways, such as disbursing loans.

That may not be such a bad thing, though, says Sun’s Buyukbezci. “It allows companies to learn… score quick wins,” Buyukbezci notes. And that is how most people in the region see SOA getting deployed.

HP’s Karawi thinks the next 12 months will be exciting with many companies taking up the idea. That may well be soon. ||**||