Engineers: From Mavericks to Mainstream

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Some developers love to write off Web services as mere “market speak” or a fancy buzzword that vendors use to hype technologies that have been around for years. Many of these same developers, however, are hard-pressed to define what Web services are. Despite this lack of knowledge, as well as little experience with Web services, the past year has seen a rapid uptake in familiarity. Developers are speaking with not just more understanding of Web services technologies but also the relevance of such technologies to them. This is to be expected as more businesses move beyond a tactical approach to Web services and strategically implement entire service-oriented architectures.

From a historical perspective, Web services continually have been evolving to mean different things to different people. Five years ago, Web services promised a simplified solution to incompatible programs trying to communicate over the Internet with a single set of specifications backed by the large vendors.

Over time, however, Web services have become anything but simple. The backbone protocols, namely Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL), have been overloaded with specification extensions designed to address everything from security to atomic transactions.

Competition between standards — such as Business Process Execution Language (BPEL) and Web Services Choreography Description Language (WS-CDL) — has not helped. Given this level of complexity, an increasing number of developers are turning to the Representational State Transfer (REST) approach. By leveraging plain XML rather than standardized XML, REST offers simplicity, performance and interoperability compared with SOAP’s formal and more advanced capabilities. Going forward, developers will find it necessary to choose which of these two paths best suits their needs.

Aside from this lack of definition, the evolution of Web services can be summed up in three words: mavericks, maturity and mainstream. Through early adopters pioneering their development in the direction of the new specifications, Web services was able to come into its own as a mature technology.

This led to increased trust and adoption by the enterprise with more and more companies progressively pulling Web services deeper into their application matrix and exposing data from legacy systems. In turn, clients and partners would come to expect Web services capabilities from their channels and service providers.

A significant number of developers already are building Web services — according to Evans Data Corp.’s (EDC) Spring 2006 Global Development Survey, 38 percent of all developers worldwide are involved in writing Web services-enabled applications. The next year, however, is expected to see it truly become mainstream. By next spring, for example, 70 percent of all developers worldwide expect to be writing Web services applications, and 64 percent expect those applications to be deployed already.

So who are these developers writing Web services? Again, it is hard to give a specific definition. Web services can range from lightweight implementations to heavy, transaction-laden applications, meaning that the demands put on a developer can vary widely. They can be independent software vendors (ISVs), value-added resellers (VARs), systems integrators or engineers working within large enterprises and deploying internally.

They are found across all geographic distributions, with North America leading the way and the Asia Pacific region projecting the largest adoption within the next year. Web services developers tend to be more sophisticated in their understanding of programming architectures — not only do they need to possess extremely specialized knowledge (vis-à-vis databases and even mainframe operating systems, for example), developers are called to a more nuanced understanding of the overarching structure used to expose applications. By necessity, they have experience with a broad range of languages, from traditional object-oriented languages such as C/C++ and Java to scripting and mark-up languages. Web services developers can have strong preferences regarding Java EE or .NET, but nonetheless, many find themselves targeting both frameworks.

Not only are many Web services developers faced with the unenviable task of integrating disparate platforms and server technologies, they also are expected to provide increased functionality and cost savings. This is especially true for enterprise developers. Needing to support large systems or networks with extremely high transaction volumes, they must answer serious questions of security and scalability with little tolerance for downtime. In some cases, they also are given the task of extending Web services applications to mobile devices. According to EDC’s Spring 2006 Web Services Development Survey, 51 percent of Web services developers project mobile deployments within a year.

While it is true that rolling out Web services can demand a great deal of developers, one generally does not find reticence or resistance to entering this space. Developers have been fortunate, in that most of the large vendors not only offer education services and technical training for their Web services or service-oriented architecture (SOA) solutions but certification programs, as well. Some certifications can be quite specific — such as IBM’s Certified SOA Solution Designer and BEA’s SOA Enterprise Architecture certification programs — while others are designed more around the frameworks that developers use (e.g. Sun’s certification for Java Web services or Microsoft’s certification for .NET). Web services developers also cite the need to have a close relationship with support. Whereas developers in other areas can first turn online for answers, few Web services developers have the time or luxury to post their problem to a forum and simply hope for a response.

The availability of certification and training for Web services speaks to the maturity of the technology. Comprehensive universal description, discovery and integration (UDDI) registries and libraries, as well as developer programs targeted to Web services, further underline the richness of resources available today. All in the name of progress, these are driving Web services more into the mainstream. For developers pushed onto the defensive by Web services who find themselves adapting as problems arise, or for developers who are not out in the market seeking to become fluent in Web services skill-sets but are obliged to do so because of client demands, such richness is a positive thing. But what about the mavericks — where are they?

When engineers were asked in EDC’s 2006 Developer Marketing Patterns Survey what motivates them the most to work in software development, more than half (53 percent) said it is the logic and challenge of programming. With this attitude, it should come as no surprise many developers are eager to push the envelope of Web services. This means creating mash-ups and carving open new areas of development. Forget support, they say, turning to Google and the online community. For the mavericks, certification is largely a non issue. Some even remark cynically that certification never helped them get a job. Instead, their instinct is to not get tied into using a single vendor and to keep their options open as new technologies come online. “Open” being an operative term for them, it’s no wonder they turn to Slashdot or Linux Today for information. And as they push the functionality of cheaper open-source alternatives, when asked about their vision of the future of Web services, their answers are more likely to include the Linux, Apache, MySQL, PHP/Python/Perl (LAMP) stack or Asynchronous Javascript and XML (AJAX).

Regardless of where developers stand in the Web services ecosystem, whether they are just adopting or are old hats, it is safe to assume the vast m

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|