Talking Web Services with Software AG

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

With service orientated architectures (SOA) gaining more and more attention these days, CIO Update caught up with Theo Beack, Software AG’s chief SOA architect and director of the company’s newly unveiled SOA Competency Center for a discussion about what SOA is, where it’s at, and how it stacks up against more traditional integration technologies such as EAI.

CIO Update: Theo, what is your definition of SOA?

Beack:

“What’s really interesting is I’m involved in the OASIS SOA reference model to implement it and just the discussion around ‘what are services’ have been raging for a year plus.

It’s something often times that people read white papers and they read articles on SOA but they don’t really know or understand what it is and how it is applicable to them.

I prefer to keep it very simple. How I view it is, SOA is an approach of how you allow applications to interact with one another. It’s a way of solving different types of integration problems and also business problems through a services approach.

That’s really what it’s all about. The approach isn’t a technology, it’s not a set of products you can use. It’s really a discipline of how you solve these problems: How do we create efficiencies within the business? How do we automate specific business processes to reduce cost or be more productive.

Ultimately, the problem IT is faced with is how to make that work: How do they take these diverse set of applications and how do they expose things to one another in a loosely coupled way? How do they make these things understand one another in a consistent and standard way?

And I really think that’s really what starts to drive SOA, is it really provides a standardized mechanism for integrating these different systems and applications with one another.”

But isn’t that the problem; a lack of standards?

Totally. And what we see with SOA is standards are really the driving force behind adoption; either XML or web services and even within that you have finer grained specifications or standards, if you will, that drives certain aspects of the architecture such as how do you secure the services you are creating or how do you orchestrate the interaction between different kinds of services, etc.

Is that WS Policy, WS Federation, etc. that are coming out of OASIS?

Correct. Or BPEL, the business process execution language, for web services and, then, for security, we would see things like SAML and WS Security playing an important role in securing these services.

Since these standards all revolve around web services, is web services the backbone of SOA?

To a large extent I think web services are implemented in most SOA implementations. Web services really plays an important role but it’s not the only means of integration.

We find many organizations prefer not to use web services but to use XML or a REST-based approach to services. So, the bottom line, is there are different ways you can expose services in your SOA architecture but, far in large, the web services and standards are used in the large majority of SOA implementations.

Does SOA require changing you existing architecture, platforms, and infrastructure?

This is where we are starting to see the value of SOA: the amount of reuse you potentially can get out of your existing applications and infrastructure Because, as you mentioned, it really would be a risky proposition and quite expensive one to rip out your applications and to replace them with so called SOA- or ws-enabled applications.

So, what most companies are trying to achieve, is as much reuse of existing applications—either packaged or homegrown. And if there’s legacy applications in the infrastructure … what they try to do is expose and wrap those existing applications as services so they get reused without having to rewrite the application or to replace them with new kinds of software.

Loosely coupled. I hear that term used a lot in association with SOA. What is your definition of loosely coupled?

Loosely coupled means that when a consumer and service producer connect to one another, that they do not know and do not care about the details of, say, the service or the consumer.

So, when a consumer, like a portal application, … they don’t need to know physically where (the service) is located, which platform it resides on, which language it’s written on, which database is used. All it needs to know is just the interface … so, what loosely coupled really means, is abstracting or hiding the implementation details between the service consumer and service provider.

Is SOA more or less complicated than traditional EAI activities?

It’s a bit of a loaded question. In some cases it’s full as complex as EAI. EAI plays an important role in many SOA architectures. The main distinction I see between EAI and SOA is EAI still remains proprietary. You either had to use specific messaging protocols and transport mechanisms; you had to use proprietary adaptors to enable this.

With SOA, everything is exposed in a standard way so it doesn’t really matter if you are using a Tibco Rendezvous or MQ or J-Messenger for you messaging. When you expose that service what you are exposing is the service interface and the underlying technology used to transport the message or to enable the interaction with the underlying application.

So, even though EAI plays a role, the subtle difference is SOA is really standards driven and it doesn’t matter what underlying EAI technology you are using.

Where the complexity starts to come with SOA is the management of the infrastructure and the services. Because you have the ability to create all these services you really need to find a way to manage them.

And what we’ve seen up to now is organizations have really paid little attention to how they manage the environment, how they manage and monitor the services, and how they use them through the development and deployment lifecycle.

I think in 2006 we can expect to see a lot more activity and really a lot more focus on the governance issues and aspect related to SOA.

What are some of the most important technologies underlying SOA right now?

I see four sets of technologies. One is the legacy integration aspect. The second one is the ESB (enterprise service bus). We see the ESB playing an important role in most architectures.

The third one is the role SOAP and XML firewalls are playing. I think that it’s a too often overlooked aspect of the architecture, that security is extremely important when you create services. And this is where SOAP and XML firewall play a crucial role in securing the infrastructure in a consistent fashion.

What we find with XML and SOAP; whole new attack vectors are opening up and the purpose of SOAP and XML firewalls is they compliment the existing security infrastructure in securing the actual XML and SOAP traffic that is flowing through the network itself.

And the fourth aspect of technology that I think is going to play an important role is the role of the SOA repository.

What we find is organizations are really starting to create a lot of services. The problem they have, however, is how to manage these services: What metadata exists and to find these things, how to know who are using them, how to do impact analysis and deciding which of the relevant services to use.

And up ’til now, very few organizations have implemented these types of repositories within the infrastructure and it’s creating a lot of oversight and management issues during the lifecycle.

The SOA repository will allow developers to document these services and to go and discover and locate the appropriate service to use. It’s much more than UDDI … what I’m talking about is metadata related to those services: who is the owner, what is the SLA of this services, etc. and describe the other artifacts related (to the service).

The UDDI doesn’t allow you to interact with the repository on that level. It’s really just a registry for the services that exist.

Even with all that’s been written and all the talk about IT as a service provider, SOA is still in it’s infancy isn’t it?

I would say so, yeah. About a year ago we were educating people on what SOA is. But in the last year, especially in the last six months, we’ve really started seeing the trend change. When people or companies engage us they don’t want to talk about what SOA is but where do they start and how do they take the first steps to implement an SOA.

So we’re really starting to see that aspect of it maturing. But, in terms of the actually implementation, I think most organizations have a long way before they can say they have a mature SOA implementation.

This article was first published on CIOUpdate.com.