4 Steps To Better SOA

In NASA's effort to integrate data from many different sources, the space agency wanted to take data collected during a feild expedition, including sample data, photos, voice recordings, and GPS information and integrate it with satellite imagery, GIS data, and information about the characterstics of the minerals found in the samples. Not only were the types of information heterogeneous, but the formats ranged widely from spreadsheet files to SQL databases to WebPages.

It's a common programming problem. Lets say, you have feild in two seperate databases, that are both named 'temp', is it legitimate to assume they represent the same quantity and can be integrated together? One might represent temperature and other temporary value. To properly combine these 2 fields, you really need to understand what the data represents.

At NASA and other large entities - both in government and business - integrating heterogeneous data is a challenge, but it's one that must be faced in order to easily share information internally and with outside partners. The integration challenge is one reason why NASA and many organizations are turning to SOA combined with semantic integration. As we know SOA consists of services that offer interoperability capabilities built into the network. While SOA's business-centric approach has sparked enthusism, the challenge is now to build in inference capabilities to make intelligent and dynamic selection of Web services possible. This is where semantic technology - the modelling of an area of knowledge like biology or economics as close to natural language as possible - comes into play.

Semantic technology

A SOA platform with built-in inference capabilities can let companies make runtime decisions based on service capabilites and invocation context where tasks are executed based in pre-defined conditions. On its own, SOA does'nt have this capability, but with the addition of inference, SOA gets the semantic richness it needs to make runtime decisions. Semantic integration techniques build context and awareness of the underlying services and data in a metalayer.

Ontology-Enabled SOA

Semantic integration techiniques are based on the idea that it's possible to find patterns in the origin of various pieces of heterogeneous data. Once done, then it's possible to define these patterns using a metamodel, and then connect several metamodels by defining how they relate to one another. One emerging approach to semantic integration is ontology. Ontology is a structured representation of a domain- by which we mean an area of knowledge like biology or economics - in terms of classes and interrelationships between the classes that can be defined using the XML-based Web Ontology Language.

There are 4 steps in building an ontology-enabled SOA:

Step 1 : Analyze the Business Process: In execution of business process, conditions may represent intelligent routing decisions requiring semantic power. We define these as "points of variability", or areas where inference capability is required. Future business needs may mandate additional variables or new values for existing variables. Identify them.

Step 2: Construct the Ontology Model: Ontology is defined in terms of concepts and relationships. Ontology concepts are implemeted in classes. Relationships are implemeted in terms of "object properties" and "data types properties".

Step 3: Create Context-Sensitive Invoker: Creating the runtime component that consults the ontology and makes dynamic context-sensitive service invocations in the next step. The business process flow can be encapsulated as a linear process in a BPEL, block.

Step 4: Web Services: provide the actual business service. They're the "consuming" point, invoked to acheive business functionality. The policy that operates on the Web Services is part of task required to incoporate a new service end point.

Final Word:

Ontology can be used to enable semantic integration by modeling the business domain process as a workflow, and constructing an ontology model along-side the business process modeling. The classes and relationships of the ontology model are created based on the domain knowledge and the business process.

High Level Overview of Service-Oriented Architecture (SOA)

Service Oriented Architecture or SOA is a systems integration architecture for the development of loosely coupled and distributed applications in an enterprise. SOA encompasses many services found on the network. These services communicate with each other and the communications involves data exchange and even service coordination. Generally SOA can be classified into two terms Services and Connections.

Services:
A service is a function or some processing logic or business processing that is well-defined, self-contained, and does not depend on the context or state of other services. An example of a service is Loan Processing or online booking of a flight. Another example may be a Weather Service, which can be used to get weather information. Any application (Service Consumer) on the network can use the Weather Service (Service Provider) to get weather information it needs.

Connections:
Connections are the link of connecting self-contained distributed services with each other, it enables the Service Consumer and Service Provider to communicate with each other. For Web services, SOAP over HTTP is typically used to communicate between services.

The following figure is a simple example of the service-oriented architecture. It shows how a service consumer sends a service request to a service provider. After accepting the request, the service provider sends a message back to the service consumer providing it with the information it needs.

SOA is different from other integration architectures, because it consists mostly of loosely coupled, highly interoperable application services. Services can be developed in different development languages (such as Java, .NET, C++, PERL, PHP) and the software components become reusable. For example the same C# service may be used by a Java application. A WSDL defines a standard, which allows different SOA components/technologies to talk to each other.

Sources:
http://en.wikipedia.org/wiki/Service-oriented_architecture
http://www.roseindia.net/webservices/

What is Service Oriented Architure?

Source: http://www.youtube.com/watch?v=zV860odGN5Y

What is the hype on SOA ?

As corporations go global and fast forward acquisitions the IT team starts facing more and more challenges in integrating various bespoke and acquired applications. It has been a nightmare for the IT team when there is a deadline given by business to integrate applications which have never been designed with open interfaces.

Hence, to reduce the painstaking effort of re-inventing the wheel everytime, software programmers started thinking, exploring and delivered smarter programs - in a way that pieces of their code could be used "off the shelf" which can be reused and better maintained and supported in the future.

"SOA (Service Oriented Architecture) is a new approach to building IT systems that allow businesses to leverage existing assets and easily enable the inevitable changes required to support the business"(Ref 1)

The basic building blocks of SOA architecture is to build applications around reusable components and define guiding principles of reusing them.

The challenges of integration that an IT team face has been in existence from times immemorial. In the good old days, the only way of integrating 2 different systems was to use a API (Application Programming Interface) call from one application to the other to fetch data which was embedded in the application. The coding was pretty tiring and cumbersome and had to be modified for each and every program requesting for a subset of the same data. With the new SOA way of systems development, things became much easier - instead of programs embedding calls to each other in their source code the new way of development use "defined protocols" ( will be explained later) that describe how programs pass and parse data.

Some feel that SOA is just a revival of modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s) . In some respects, one can regard SOA as an architectural evolution rather than as a revolution. (Ref 2) . It's a ongoing advancement of taking the best from the past and overcoming the drawbacks that classical programming had.

So, what are the benefits that SOA bring. According to a published article in ComputerWorld ( Ref 3), here are a few of them :

1. Application integration savings: Having a service-oriented interface to each application can save 30% to 40% on each integration point. Rather than point-to-point integration, SOA has a hub-and-spoke configuration, reducing integration points substantially.
2. Reuse of applications: An application to retrieve and report on employee data from a human resources database can be used as a service by identity management systems, employee portals and other applications, rather than redeveloping the code or embedding it in each of these applications. The direct benefits are immediate avoidance of development-and-test labor costs. And as an organization moves more applications to SOA, reuse benefits grow. Short-term savings are typically 5% to 10%, growing to 40% or more for an enterprise wide deployment.
3. Reduced project risks: Since the "reusable components" have been already tested and deployed it reduces the risks of deployment of the same code in future projects.
4. Improved application quality: Reducing application integration complexity and allowing reuse also improves application quality.

We will try explaining the technical aspects of SOA, the business perspective and the challenges faced on Implementation of SOA in the next few sessions.

---

Ref 1 : Service Oriented Architecture for Dummies, 2007, ISBN - 13: 978-0-470-05435-2
Ref 2 : http://en.wikipedia.org/wiki/Service-oriented_architecture
Ref 3 : http://www.computerworld.com/s/article/9001155/Is_There_Real_Business_Value_Behind_the_Hype_of_SOA_?taxonomyId=74&pageNumber=1