How Web Services Can Boost Dev Productivity
In this case study, IDN takes a look at how the proper use of .Net, SOAP and XML tools and "project targeting" strategies are fueling developer productivity. The proper combo of tools, talents and the right project are enabling one developer to do the work of three at one dev shop, even when taking on tough custom GUI and integration projects.
In this case study, IDN takes a look at how the proper use of .Net, SOAP, XML and web services "targeting" strategies are fueling developer productivity -- enabling one developer to do the work of three when taking on tough custom GUI and integration projects. And, this is not the result of a big corporate budget or a long-term research. These results are coming from a children's charity.
The Annie E. Casey Foundation, a non-profit firm dedicated to helping disadvantaged children, is looking to web services to speed their grant approval process by speeding workflow among staffers and improving integration with backend data.
It's not that the Casey Foundation is hell-bent to be cutting-edge. Rather, their execs have found that web services are a low-cost, low-hassle way to get their systems -- and people -- to work better together. In fact, at Casey, they've contracted to do a web services project that will boost their productivity immeasurably, and yet it will take only one contract developer from Ajilon Consulting less than two weeks to do the job.
"The standards, skills and tools needed for web services may be on the brink of critical mass to allow many small and mid-sized organizations to begin to consider projects," John Keefauver, .NET business manager at Ajilon, told Integration Developer News.
The Power of SOAP, XML
The ability of SOAP and XML to provide practical and powerful integration benefits can be illustrated at Casey Foundation, comments Jim Lane, the Ajilon senior developer in charge of the project.
The Casey Foundation currently uses an off-the-shelf software package that doesn't match their business process. While developers have tried to tweak the package where they could, they have decided to undertake a web services overhaul that would enable their employees to access their grant approvals applications directly from their central web-based portal system.
The scope of the project provides Casey employees with several key benefits:
(1) direct browser-based access to a traditional client/server application;
(2) integration of the grant approval workflow process with a more user-friendly system for posting notations to an individual grant application document; and
(3) a "polling" feature that would alert employees that the grant system has a pending grant approval document waiting for their input.
Architecting the Solution
"One of the biggest needs Casey had was that their current system must be accessed directly from a Windows desktop, which limited the kind of access employees could have," Lane told IDN. "Casey also wanted to have better workflow, and a way for the software to alert them as to when work was in their queue." Lane said a web services approach based in XML and SOAP would provide solutions to both problems, and at a lot lower cost and time than would have been possible several years ago.
Lane's first step was to map out the new and legacy assets that Casey could bring to bear for the project. He found that Casey uses an intranet portal server built using Java and Unix technologies that all employees use to log into email, news updates and other company bulletin information. "It's set up like a message center," Lane said, "and all of Casey's current users are used to going in and checking their message announcements through a web interface that they're familiar with."
The grant approving application, which currently runs on a separate server, now requires each employee to log in directly from their Windows desktop, not a browser. Lane's job is to swap out the old restrictive grant approval application for a more flexible version, which in turn will be tied into the central portal -- and even given its own more user-friendly GUI to allow users to post notations into each document from their browser.
Just a few years ago, Lane said, the same job would have required him do to several custom builds -- one for linking the new presentation layer (GUI) to the backend system, another for linking the email messaging system to the workflow element of the grant application; and yet a third to provide an "alert" message in real time to the next user who needs to act on the grant proposal document.
Using HTTP, WSDL, XML and SOAP, Lane said he now has a strong suite of standards and tools that will help him handle the complex communication between the Java/Unix portal and the Windows application. "I can use SOAP to talk back and forth [between the two nodes], and use XML and a few data points to handle the conversation. All that's left is for me to work with Casey to agree on what data points they want me to use." The whole project, including providing a custom GUI for the new application, will take about two weeks tops. In fact, Lane is the only developer on the project.
Are Web Services Really That Easy To Deploy?
Is it really that easy? Lane insists it is. "The conversation [between the portal and application servers] will be using HTTP and it will handle the SOAP call which will be embedded with XML data," Lane said. And because SOAP is self-describing, there won't be the need for a complex message queue or other middleware hand-off, he added.
The actual transmission will be an XML document embedded with various pieces of information, some of which will define who the information is for and how it is to be handled, Lane said. "So, the points we'll still need to define and parse out are very detailed things like whether Casey wants to send a numeric ID or a name to identify who gets the XML document."
Lane said his use of a SOAP toolkit (specifically, Microsoft's SOAP toolkit in Visual Studio.NET) was key to his ability to do the job in so little time. "Microsoft's Visual Studio.NET's support for SOAP takes care of a lot of the work we used to have to custom code," he said. Lane said he did some work with XML HTTP several yeas ago, and in that project he had to "build up the SOAP packets myself," which meant doing (a) event modeling, (b) object substantiations for all of the objects needed for communications, and even (c) loading a DOM with the up to dozens of nodes that represent the discrete pieces of information inside an XML document.
Putting his web services project in a broader context for traditional web developers, Lane offered the following analogy, "Not using VS.NET would be like trying to create a data-aware web page in notepad or some other test editor. Sure, you could do it, but the efficiencies you gain by using tools like Visual InterDev or Visual CafÃ© are just incredible."
And, it's not just Microsoft that's helping Lane deliver the project in such quick time, Lane said. Infragistics, Inc., a toolmaker for ASP, .NET and Java developers, knows the data abstraction of ADO.NET to populate the data tables - another time consuming task that Lane said he used to have to do by hand.
As a result, Lane suggests developers keep checking on the maturity of web services standards and the maturity of the tools that support them. "One of the biggest lessons that I've learned is that efficient and great tools are coming out for all sorts of web services support that will let developers avoid sitting down and doing this from scratch," Lane said. In fact, Lane said it might surprise many developers just how much web services standards such as SOAP will provide a "higher degree of control and granularity" for integration projects.