Welcome to HashDot.com
Search  


Contact Us

Earn Money
Earn money online, For lifetime Hashdot membership and for Advertisement details..
Click Here

Login




 


 Log in Problems?
 New User? Sign Up!

  

Software design finds a fresh path

(1653 total words in this text)
(1060 Reads)  Printer-friendly page
<div align="justify">

Get ready for service-oriented architecture (SOA), the next big thing in software. Heard it all before? Perhaps, but that doesn't mean it's not going to happen.

SOA looks like it really can revolutionise the way IT supports business: not just by making IT development better and cheaper, but by positioning technology more closely to core business processes.

It's essentially a software design approach that uses web services technology to break applications into components that deliver functions in the form of services.

Analyst Gartner believes that SOA will become the dominant model of software creation over the next five years. Indeed, it even suggests that failing to adopt the model will lead to competitive disadvantage.

"Mainstream enterprises should invest today in understanding SOA and building SOA design and development skills," Gartner advised clients in a research paper earlier this year.

The claimed advantages of SOA mostly boil down to flexibility and cost. Applications should become easier to build, manage, reconfigure, maintain and change. And because they will be more modular, their development and rollout can be more iterative and manageable.

In addition, reusing blocks of functionality in different contexts means that functional duplication between applications can be cut, slashing development and maintenance costs.

"The number one benefit for us is probably software reusability, although maintenance should also get easier," said Jon Higgins, head of e-commerce development at Tesco.com, which is migrating its IT infrastructure to SOA. "You get more from the code, and the return on investment is better."

The project is expected to take about a year. "It's a fair chunk of work," warned Higgins.

For the past couple of years, businesses have been grafting web services interfaces onto existing applications.

This process, known as 'wrapping', allows disparate applications - or parts of applications - to talk to each other. In technical parlance, an application's functionality is presented or 'exposed' to other applications as a service.

So far so good. The next step is a fundamental rethink of the way applications are created and operate.

Instead of creating links between different applications or between applications and business processes, we need to embed the linkage between IT process and business directly into the very fabric of the software.

Web service management

SOA has been around for decades as a general approach to software development, but is only now breaking into the mainstream as a way of organising and managing web services.

Without web services, SOA is an almost academic exercise. Without SOA, however, web services will degenerate into chaos. SOA provides web services with the rigour and intellectual respectability it needs to succeed.

Together, they promise to allow software to be designed more easily as chunks of business functionality that can be combined and reused in different contexts to create applications that closely support business processes.

"Web services is a fantastic thing, and we make use of it, but it simply exposes application functionality as a service," explained Higgins.

"SOA is about understanding the business processes within the organisation and then creating software services that support these business functions. It's about understanding business requirements at the developer level."

With software assembled more easily, developers should be able to focus more on business-oriented tasks and less on technology.

"Developers will spend a lot less time down at the technical plumbing layer, allowing them to concentrate on the higher levels where they can add more value and make the company more competitive," said Bob Sutor, worldwide director of WebSphere infrastructure software at IBM.

"You get a collapsing of complexity and you can configure systems much more easily. This in turn will mean that business rules can be changed more easily by business people, rather than by software engineers."

The hope is that a greater number of business-oriented, but less heavily technical, IT staff will play more of a role in creating large scale applications.

Mark Pritchard, a senior European software architect at BEA Systems, argued that SOA will shift tremendous creative power to IT staff working within or closely with business units.

These staff create user-friendly applications with low-level tools such as Visual Basic. Such applications are attractive to users, according to Pritchard, but often don't scale across the organisation. Consequently, they are rejected as technically inadequate for company-wide rollout by the central IT staff.

SOA should give business-oriented developers powerful software components - built by the central IT staff or by software houses - which they can use to build truly scalable applications.

"SOA bridges this gulf between the IT communities within the organisation. It will remove a huge source of frustration for IT managers," said Pritchard.

Changing mindsets

However, we're not necessarily ready for all this. When the world suddenly gets more complex, coping with change becomes a major challenge.

"IT managers have to move from thinking about applications to thinking about services and how they support applications," explained Kieran Mockford, architectural software engineer at Microsoft.

Vendors must develop application management and monitoring tools that show the status, not only of applications themselves, but of services too. The mindset change may be toughest at the top. Design tools already make it easy - frighteningly so - for junior staff to create new SOAs.

The tough part is to create 'joined-up applications' in a planned manner, rather than just churning out web services at random and hoping that the resulting patchwork of functionality will somehow fit together.

"Microsoft encourages you to think of web services as simple and easy to create. But creating the right one isn't so easy," warned Uttam Narsu, vice president at Forrester Research. That's where the discipline of SOA comes in.

At Tesco.com, Higgins argues that the toughest part will be implementing new systems in tandem with the current infrastructure.

"The intellectual challenge isn't that great if you already have a good architecture, and software development tools already make the software development pretty straightforward," he said.

"The hardest part is introducing new business rules and infrastructure change while keeping compatibility with what's already there. We can't just turn our whole website off for a couple of months."

A major problem is the fundamentally dysfunctional nature of many larger organisations, with departmental fiefdoms at war with each other.

How can businesses achieve software component reuse if they're heavily decentralised into self-contained 'silos' and IT departments are increasingly slimmed down?

There are also many unsolved questions, including some messy legal issues. Today's software licensing, for example, just doesn't fit with the componentised, super-flexible world promised by SOA.

How can you allow external partners to access a packaged application that you've turned into a service if the software house has only licensed your organisation - and not your partners - to use that software? Or what do you do if the software is charged per user?

And, of course, it's never going to be as good as the vendors promise. For example, most sell the idea that the pre-tested 'black box' nature of service-oriented software components means that application testing will suddenly become much easier and cheaper.

"Each of the building blocks needs to touch only a few of the others. Therefore each piece doesn't have to be tested against every other piece. This allows faster development and allows the users to build services faster," argues Samuel Starr, chief executive at software tools designer Sterling Commerce.

That's the theory; the reality may turn out differently. "The idea that you don't have to do detailed testing assumes that the web service is a perfect implementation of the interface. But can you really take that risk?" asked Narsu.

In fact, the testing of services may well be more complex because designers don't know who will be using them and therefore have more possibilities to test for.

SOA will deliver much, but it has its limitations and it's no cure-all. "You're not going to make everything a service. There are things that you don't want to expose as services," said Phil Murphy, a research director at Forrester Research.

Moreover, SOA can be a complex affair, and some types of functionality may better be delivered by simpler, if less powerful, technology.

Although Gartner predicts that SOA will pretty quickly become dominant, it doesn't think it will wipe out traditional technologies. And we can probably forget the Utopian visions being peddled of applications being completely dissolved into ever-changing combinations of components.

That's almost certainly too complex for us to manage. Applications will survive, albeit in more modular form.

The difference is that they'll be better created and orchestrated, and they'll support business processes better. And that can't be bad.

SOAs: WHAT THEY DO

Service-oriented architecture is defined by Gartner as a way of designing software in which applications consist of one or more services and clients.

A service is a software module that carries out a task (such as adding a new customer to a database) and which is accessed via an interface. A client is a module that invokes these services.

The interface acts as a contract that defines the identity of the service and lays out its operating rules. The other service element is the implementation: the software that carries out the tasks as promised by the interface.

Clients should know nothing about the inner workings of a service. Everything they need to know should be contained in the interface alone. In this sense, each service is a 'black box'.

SOA is loosely coupled, meaning that any service should be capable of working with any client, irrespective of operating system and hardware.

This allows easy reuse of software code, a key benefit of SOA. Traditional applications are tightly coupled, meaning that their elements are designed specifically, or even exclusively, to work with each other.

SOA is also coarse grained, meaning that a service carries out an entire process, rather than a small part of that process. So services make life simpler for the developers who use them.

New services can be created either by writing a service from scratch, or by wrapping functionality found in an existing application.

Wrapping means repackaging some or all of an application's functionality as a service, essentially by writing a new interface for that functionality. Wrapping is popular because it protects investment in existing IT infrastructure.

</div>

Web site powered by PostNuke ADODB database library PHP Language

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest (c) 2008 by me
This web site was made with PostNuke, a web portal system written in PHP. PostNuke is Free Software released under the GNU/GPL license.

You can syndicate our news using the file backend.php