A few years back, when i was a consultant, I went through a period of a year or two when it seemed that every client I spoke with was absolutely certain he needed a Web Services solution for his business. Of course, not many of my clients actually understood what that meant or the reasons why they might need that kind of architecture, but since they kept hearing about Web Services on the Internet, in magazines, and at trade shows, they figured they’d better get on the bus before it was too late.
Don’t get me wrong. I’m not against Web Services. I’m just not a big fan of making technical decisions based solely on whatever happens to be in style at the moment. This chapter will address some of the reasons for using a Web Services architecture, as well as explore some of the options to consider when integrating systems with the outside world.
In this chapter, I’ll walk you through a real-life project that involves exposing a set of services to a business partner, and discuss some design choices that were made along the way. Technologies that were used included Java (J2EE), XML, the Rosettanet E-Business protocol, and a function library used to communicate with a program running on an AS/400 system. I will also cover the use of interfaces and the factory design pattern as I show how I made the system extensible for future distributors who may use different protocols and may need to access different services.