Home > SOA Tips > The Web Services Advisor > A day in the life of a Web Services Architect, part two
SOA Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

THE WEB SERVICES ADVISOR

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


Preston Gralla
07.22.2003
Rating: -4.50- (out of 5)


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   



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.



Rate this Tip
To rate tips, you must be a member of SearchSOA.com.
Register now to start rating these tips. Log in if you are already a member.




Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   



RELATED CONTENT
The Web Services Advisor
What to expect with the new JavaScript standardization (ECMAScript 5)
Restlet framework wrestles RESTful Web applications
3 tips for choosing whether to use EGL
Use SoaML to facilitate Model Driven Architecture
Enterprise mashup patterns act as API enablers
XQuery learns to write using XUF
Descriptive Languages for RESTful Services
Notable Python language update on view
Try XML-based Extensible Business Reporting Language (XBRL) for accounting reports
Whatever happened to ''X''?

Why enterprise architecture?
Architecture 101: Why SOA needs an enterprise focus
Vendor-oriented architecture hampers SOA – Zapthink
Architects: SOA masters or lost in translation?

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary

DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.



SOA Trends and Strategy - SOA Education, SOA Development, SOA Implementations
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2001 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts