Today, an SOA architecture that utilizes a "packaged" ESB is clearly at the top of the list of the enterprise software vendors, such as, IBM, Microsoft, BEA and Oracle. ESBs are essentially all about integration and in some ways there is nothing new here at all--routing, transformation and system integration.
What is different are the considerable number of customer facing Web Service standards that work in conjunction with a modern ESB in a seamless fashion. Not since the ill-fated DCE (Distributed Computing Environment) has there emerged a model that can truly support the disparate technologies of the enterprise. However, just as DCE, which had a reputation for having long lead times for software releases and being hard to administer, a true SOA represents a complex software architecture.
So, beware the mythmaker. The mythmaker usually recommends that you have to teardown the old technology to make room for the new. However, Web service and application point-to-point integrations are time consuming and expensive projects. A technical strategy is required to move the organization to an SOA over the longer run that includes integration with legacy technologies. For organizations of any scale, a methodology and release strategy is required; any other approach would be a fools errand. It is better to face the fact that provisioning, integrating and managing services is hard work. This isnt like build stunning, flashy, experience design Web sites; integration implementations are, for the most part, painstakingly tedious, operator-less processing style programming efforts.
Strategy and Methodology
SOA and Web services are, for the most part, an improvement in B2B technologies and standards for the Internet, including XML. An SOA doesn't necessarily mean you must expose all services as Web services, but there's a strong case for implementing B2B functionality as a Web service. So, during the discovery phase of an SOA project, a good candidate for a Web service is B2B functionality. Conversely, the technology doesn't have to be limited to B2B. It does represent a bridge technology for communicating between disparate environments; however, the SOA model, which uses Web service as its enabling technology, addresses a more complex problem set.
Although, even season architects disagree on:
- What constitutes a solid Web service?
- What types of applications or processes should be converted into a Web Service?
- How fine-grained should the Web service be?
- When and how should an ESB be utilized in the architecture?
- What protocols should be relied on?
Indeed, a colleague of mine stated that to be a service it should be extendable. In my opinion that is exactly what you don't want; reuse of Web services is not gained through extendibility, but by making the service available to many consumers. This is an age old object-orientation controversy, essential, when to extend an object and when to embed it.
Nevertheless, many organizations that have implemented an enterprise-wide portal technology have realized through that process that a certain amount of guidance is required to insure success. At the minimum, identify a set of SOA artifacts before pursuing an enterprise-wide SOA and develop a roadmap, like that in Figure 2.
A recent Network Computing poll indicated that about, 54 percent of respondents said they have implemented ESB or will do so this year. Although, out of this group, it appears to be indeterminate how many respondents actual have already implemented an ESB. Granted a concise definition of ESB could be an illusive. Basically, an ESB has routing, transformations, and protocol support, orchestration and integration capabilities. Respondents indicated that the biggest barrier to ESB integration was the lack of technical expertise and security concerns. Fortunately, any lifecycle methodology worth a salt would address these issues during the scope or design phase.