Like application servers, the basic IDE market is becoming commoditized and tools vendors are forced to adapt. Fortunately, web services, Service Oriented Architectures and grid computing emerged, giving companies something to aim for. How ISVs evolve to tackle web services, SOAs and grid will determine who is successful and who fails to survive during the coming years.
While we’ve all heard about web services, it is their manifestation as a component element of SOA-based applications and grid that should be at the back of companies’ minds today.
Web services support fails to differentiate
During the last few years, ISVs rushed to announce that their tools supported web services. However, just four-short years into their life, web services support in itself has ceased to have any meaning as a competitive differentiator.
Instead, web services interfaces, such as WSDL, are seen as something that can be built into applications during the development phase of the software’s lifecycle, meaning they can run inside web services management suites, monitoring things like quality of service and potentially respond to changing business demands. That, in an acronym, is SOA.
The need for resources knowledge
Only, SOA requires a little something extra than a web services interface: it requires knowledge. That is, knowledge of your company’s network-based hardware and software resources. Without that knowledge, you are essentially building software in a vacuum, and throwing it over the fence to the deployment folks who configure the application to suit local conditions and ad-hoc fixes. Software ceases to have a services-oriented component.
It seems as if at last three major vendors have recognized and appear to be expanding the scope of their tools’ application lifecycle management abilities to encompass the need for knowledge of hardware or software resources. Those companies are Borland Software Corp, IBM Corp and Microsoft Corp, which are in different ways moving in this direction.
Borland’s recently unveiled Development Op-Center, cross-platform suite helps developers take into account knowledge of systems in the runtime world while also automating applications’ deployment via XML templates.
The company already provides performance management software, but Development Op-Center by incorporating more system considerations into the build phase for inclusion in the templates, subtly assists development of more SOA-based applications by closing the gap between developers and run-time IT staff.
Borland’s Java tools rival IBM, meanwhile, also wishes to close the gap between design tools and runtimes, achieving a more common look and feel between and also easier installation of applications. Already, IBM is planning an Eclipse interface for developers building applications on the next edition of its DB2 database, codenamed Stinger, due later this year.
And finally, Microsoft is preparing Whitehorse, the codename for an application modeling runtime and framework that, the company promises, will suck data into the build process about server and PC set-ups.
What needs to be done?
Much has been written in recent months about ISVs taking steps to simplify development of Java, for example, using drag-and-drop in attempt to appeal business-level programmers. While laudable, this strategy alone does not tackle the design aspect that helps programmers move further towards the concept of SOA. That will come from factoring more run-time considerations into the design phase of ALM.
Borland, IBM and Microsoft have a long way to go, but by tackling this particular piece of the puzzle now, it should help them stay ahead of other companies, and even some major platform vendors currently pushing their own development tools.
This article is based on material originally published by ComputerWire
This article is from the CBROnline archive: some formatting and images may not be present.
Join Our Newsletter
Want more on technology leadership?
Sign up for Tech Monitor's weekly newsletter, Changelog, for the latest insight and analysis delivered straight to your inbox.