XML and .NET Ease Multi-Point Integration
See how developers at one online auto repair service married XML with .NET and BizTalk technologies to build a complex web services project that brings everything a customer could want to know about his car under one hood -- including scheduling, pricing, paying, knowing what was wrong -- and even picking out a loaner. Tips and lessons learned -- regardless of your product choice -- are also featured.
Working with web services firm Extreme Logic, JoeAuto.com developers built a customized system with a combination of XML, Microsoft .NET and BizTalk technologies, and a disciplined approach to making applications and data reuseable by developers for new projects.
Now, consumers can schedule maintenance, receive a diagnosis, obtain pricing information, make service appointments, choose a loaner car, view repairs and even make payments online.
Extreme Logic's CTO Keith Landers told IDN that languages with an object- or class-oriented structure (such as C#, VB .NET and Java) are taking on a much more extended role. Rather than a language environment for a straight vertical silo, these languages are "becoming the tools and languages for an end-to-end service architecture or a 'grid model' of computing," he added.
Landers' experience in enterprise development and his new knowledge of XML-driven web services provided a potent mix of insight and experience for solving the JoeAuto.com challenge.
Instead of viewing projects as vertical applications that need data, business rules and GUIs, Landers said developers should think of their assets as different tiers -- rather than simple silo applications, he recommended that developers consider these tiers as separate component layers that should not be breached.
"Developers must start thinking of [their code] as discrete assets that will need to be shared, exchanged and integrated across an entire enterprise," Landers told IDN. "Once you consider your software assets as the 'power' of the power plant, you see that you need to put a 'service grid' in place to deliver, monitor and manage that power to the different nodes," he said.
Inside an On-Demand Integration Architecture
JoeAuto.com wanted to deploy a workflow solution to integrate vital processes from auto check-in to cash-out. Providing customers online efficiencies is key to the JoeAuto.com business model, as studies show that more than two-thirds of the time a vehicle is in the shop is spent not on actual repair work, but on the collection and distribution of information.
"JoeAuto.com wanted a highly interoperable solution, enabling them to connect disparate systems and to integrate supplier vendors. They also wanted a reliable real-time capability for notifying customers instantly when repair-related events occurred in the shop," Landers explained.
When drafting the architecture for JoeAuto.com, Landers turned to his experience as a high-level developer at one of America's best-known companies. Before coming to Extreme Logic, Landers served for five years as Coca Cola's head of application development architecture. From that perspective of supply chain, code-reuse efficiencies and inventory/commerce tie-ins, Landers became convinced that today, even departmental developers should begin to look differently at their projects.
The trick was in handling the supply chain.
At JoeAuto.com, Landers chose to go with Microsoft's BizTalk Server 2000 as an EAI server to efficiently and seamlessly tie together line-of-business, point-of-sale and corporate financial systems with the databases they rely on. The BizTalk server uses a message queue to send messages between the solution and an Anderson BDG VAST POS (point of sale) system.
The server also provides the mechanism for orchestrating event-based messages between the solution and the Great Plains Software accounting package, as well as the transformation and mapping of the requisite data. BizTalk 2000 also integrates the solution with invoicing systems and enables communications with a customer-notification component and a parts component supporting the direct order and delivery of parts to the technicians.
Using BizTalk to handle some of the tricky EAI issues also let Extreme Logic consultants push JoeAuto.com into even more aggressive use of another key standard integration technology: XML.
Paul Hernacki, another Extreme Logic designer/developer who worked on the project, said that with JoeAuto.com, Extreme decided to use XML-based documents. This approach enabled different "services" to extract and update data they needed, using a BizTalk server as the framework for taking data (from EDI, relational or flat file) and mapping it to the internal XML schema of the documents.
"We've found that when a system needs data from multiple sources, especially legacy sources, utilizing XML makes passing that data from service to service much more efficient, with fewer errors," Hernacki added.
In less than six months, Extreme Logic designed, developed and deployed a workflow application that tracks vehicles as they progress through the JoeAuto.com system. To make the application easy to scale out as the company grows, the Extreme Logic project team used a multi-tier architecture: (1) presentation; (2) business logic; and (3) data. Each layer used different tools and languages, and was constructed by a discrete development group.
The key in developing an end-to-end system is the separation of the interface, business logic and data layers, Hernacki said. Once these layers are separated in the development process -- and stay that way -- it's a lot easier to stick to a plan to develop common services that can then be reused.
The Payoff: Reusable, Networked Components
Dividing the JoeAuto.com project into discrete, reusable components -- that can easily talk to each other -- has resulted in a surprising number of integrated features for the customer, and easy management for the developer/IT management team that maintains the JoeAuto.com system and the repairmen who rely on it internally to do their jobs.
But the "components" at JowAuto.com aren't the old-fashioned CORBA-type of component code that sits on a server (or in a drawer) waiting from some other developer to find a use for it. These "components" are predefined aspects of an application (workflow, data, business rules, etc.) that are already built -- and already running in an application on the network. Sitting on a server, doing work, they await transformation into a published web service for some other application and/or user.
For example, when a customer signs up for service on the Web, JoeAuto.com picks up the car, provides an hourly-rate loaner vehicle while the car is in service, and enables the customer to see the car being worked on via webcams stationed in any of the shop's 27 service bays.
Running on desktop PCs for office staff, the solution is also available on Compaq iPaq PCs on carts in the service bays that technicians use to update their progress and to order parts that are then hand-delivered to them while they work. The solution includes online knowledge systems that provide customers real-time information, both text-based and through the webcams, on the status of work in progress.
The solution also keeps vehicle repairs and maintenance on schedule by alerting individuals and team leaders when a repair is at risk of falling behind. It also tracks time actuals and enables reporting that allows JoeAuto.com to differentiate itself to investors in terms of productivity and cost-effectiveness.
Learning Lessons from XML-Driven Integration
To reap benefits of XML-driven (or on-demand) integration, not all developers have to be architects, Landers says. In fact, fewer than 10% of developers today really know all the intricacies of building an integratable solution from the ground up -- instead, they can take some simple design steps to help contribute code that can become building blocks for an SOA- or grid-based framework.
Landers says despite the temptation to handcraft a completely integrated vertical application, developers should never break what he called "the "Titanium Wall" that separates the three tiers of application components: UI, business logic and data. "You want strong walls between each of these three elements," Landers said. This allows better scalability and reuse of code.
And there's another, less obvious reason to not break the Titanium Wall.
In an end-to-end world, your application or data's ability to deliver a result is not the result of local processing on a local server. A successful outcome is probably dependent on successful interactions with neighboring systems.
Thus, "service levels" need to be an ongoing concern as developers build their components. Developers should ask themselves, "Will my components be able to share status, information and inheritance easily with neighboring systems?" Landers put it this way: "Your underlying services, such as error management, QS and application mentoring, can work without being tied to a specific element of the application."
This approach also gives IT departments more flexible and less costly ways to cope with the ever-changing status of key end-to-end transaction standards for web services -- such as session (or state) management and security, which are lacking in the current set of web services standards and tools, Landers said. Lacking a clear outcome on standards, "more and more companies are saying 'I won't be just on one side [of the standards debate],' and this approach enables you to more quickly adjust your enterprise to whatever standards finally emerge," he added.
The more developers know about the native features and capabilities of XML, the more they will be able to build in better support for the exchanges, updates and transfers that must occur between nodes, Landers said.
To Landers, XML is a key element of the glue needed to build an architecture that delivers two basic elements:
- Scalable underpinning for data/rules/UI sharing across an enterprise; and
- Creation of a firm Titanium Wall between the development environments for business rules, data and UI.
Along with XML, Landers said his architecture approach uses business process server controllers to bring together different services and data. This technique builds a brokering server environment that enables the services to create a relationship among themselves. (In Landers' case, he has settled on Microsoft BizTalk for this function.) This gives Landers a relationship between a service request and a UI, or rules that can be custom-configured for employees based on their job roles -- or even for end users based on their account information and access privileges.
Is there traction out in the market for such an integration-driven approach to applications development? Landers says his customers like it, and the company is poised to hire as many as 70 developers in the coming few months.
The biggest reason why Extreme Logic is enjoying growth in IT demand while most of the industry is in a spending chill, Landers said, is that customer needs dictate a more flexible and cost-effective approach to integration.
"Bottom line, practically 100% of everything we do now is about integrating back-end systems together, or bringing them to work with other databases or front-end systems. But customers are also demanding the solution be flexible enough that it will scale and can be changed when standards or tools get better." That's something traditional EAI and middleware firms just don't offer, and something an SOA approach can begin to address, he said.