Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

A day in the life of a Web Services Architect, part two

In his last column, Preston looked at a typical day in Paul's life. In this column, he'll more closely examine the technology and challenges in the project he's taken on.


The Web Services Advisor
(To receive this column in your inbox,
click Edit your Profile and subscribe.)
.

Continued from Part One

Paul Farrell, senior product marketing manager for Epicor, a global provider of integrated enterprise software solutions for mid-market companies, has a task that few of us might envy. He's in the company's manufacturing solutions group, which develops solutions for manufacturers, companies that range from emerging companies and startups, up to those with about $500 million in annual sales. He's been given the job of moving Epicor's core product for manufacturing solutions from a client/server model to a Web services architecture. The target release date is early 2004, and the clock is ticking.

In my last column, we looked at a typical day in Paul's life. In this column, we'll more closely examine the technology and challenges in the project he's taken on.

Understanding the problem

The project had its genesis two years ago, when Farrell began researching what the next generation of the company's manufacturing solutions product should be. At that point, "it wasn't a Web services project," he recalls. Rather, it was more of a blue-sky exploration, with several goals. They wanted an independent technology that would not tie them to one vendor or solution; an n-tier architecture; the ability to customize and personalized the solution; and the ability to change technologies very quickly when necessary. Farrell also recognized that "the way the world is going, the information you present at the end of your application may not be received and interpreted by a person" — instead, a system may be getting that data. "So we needed an architecture that could build a framework to allow any part of the process to be collaborative, like a supply chain.

"As the project progressed, we looked at many technologies, and realized that a services-oriented architecture would deliver everything that we wanted. That led us to a Web services framework."

Another reason they decided to go with a Web services solution, he says, is that "right now Web services and .NET are snowballing, and we want to be there before our competition is."

And so for the past year, they've been working on that framework and architecture. Other Epicor divisions were working on Web services, particularly using .NET, and so the group had a starting point.

The biggest challenge, Farrell says, was to develop the overall framework for how the architecture and application would function. "There was no out-of-the-box framework that defined how you manage an application, how you do security, and related matters, and so defining that framework took a great deal of time. It took us much longer to finish that framework than the time I budgeted for it," he recalls. "But it had an enormous payback. Because we architectured it right up front, it's two hundred percent more efficient. Once that was done, everything else was straightforward."

A look at the overall architecture

The decision was ultimately made to break the architecture into two components, the back end and the presentation. The back end would handle the business logic, while the front end would be for presentation and user interface. Farrell also decided to separate his teams that way as well. So one part of the team works on the back end, and the other on the presentation.

The group working on the back end was experienced in working with Progress Open Edge technology, and so they have worked on developing the business logic in that system.

"They're developing the business logic without developing forms," he says. "They don't even know how the business logic will be used. We deliberately split the user interface from the business logic, so the teams are working separately, utterly invisible to one another," he says. "That way, the business logic could be used in other ways," not just with the specific application that they're currently developing.

For the presentation component, Farrell decided on.NET and using Visual Studio .NET as the development tool. He went with that rather than a Java development environment because "I didn't want any limitations on what I could do. We needed a toolset that allows us to do everything we want, and Visual Studio .NET is an outstanding tool, as well as the simplest and the simplest environment." Additionally, Microsoft was a marketing partner, which was a factor as well.

Ultimately, he says, he's building a architecture flexible enough so that "on the framework side, we could build a Websphere version of it, and use that in concert with Progress Open Edge…we can plug in any kind of technology framework, we can run a back end on Linux, UNIX, a Microsoft stack, it doesn't really matter," because the user interface is separate from the back end and can always be changed.

The bottom line

Several months remain before the project will be finished, but Farrell is confident that it will offer Epicor and its customers a number of benefits. Unlike the existing client/server architecture, it will not need a robust network in order to run, and so will able to be run across the Internet by a PC anywhere in the world—and PDAs will be able to access it as well. Customers will be able to easily customize the interface without having to touch the source code, since the business logic is separate from the interface. Customers will also more easily be able to integrate the manufacturing system with their other systems, such as their CAD systems, because every aspect of the product will be open and available as components.

Of course, at this point, most of those benefits are theoretical. Farrell won't know how it all turns out until the first quarter of 2004, when the project will be finished. He's confident in its ultimate success, though.

"We've put a lot of thought into the framework, and how everything will work," he says. "That work will pay off."


For related Webcasts:

For related Articles and Commentary:


About the Author

Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at preston@gralla.com.



Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close