|
The Enterprise Service Bus (ESB) "specification" is, in many ways, wide open
June 05, 2006
URL:http://www.drdobbs.com/architecture-and-design/enterprise-service-bus-part-1/188701674
Frank Teti is an industry analyst and principal architect. He can be reached at [email protected].
Some of the more interesting marketing battles currently being fought in the IT industry are over the enterprise software market. In that space, business fundamentals rule the day and some things never change--if you control the API, you control the market. Essentially, vendors with the best technical strategy, commitment to the market, and ability to execute usually dominate. The others either fall by the wayside, are acquired, or settle for their technology to be resold by larger vendors.
Nevertheless, while meta-data and model-driven programming are the wave of the future, whether the implementation is a Spring Web Flow, a standard Web service, or an ESB, most organizations have limited tolerance for protracted analysis and system design lifecycle phases, which are required to configure the these systems properly. This work ethic needs to be seriously reconsidered.
Not since the client-server paradigm shift and early days of J2EE has a market materialized with so much potential. In this market, vendor strategies range from automating the lofty, C-level, SOA-governance process (CA's Clarity, for instance) to providing search capabilities that utilize the XQuery standard (such as with Mark Logic).
XQuery, a technology under development by the World Wide Web Consortium, is designed to query collections of XML data. This does not mean just XML files, but includes anything that appears as XML, including relational databases. XQuery has broad support from IBM, Microsoft, and Oracle, as well as application server vendors such as BEA and Software AG. These vendors have clearly indicated that SOA is a primary market focus.
That said, to brand yourself as an SOA vendor, it appears that all you really need to have is a track record for building service-based software. Generically speaking, a service can be an MQSeries Manager, EJB (Enterprise Java Bean), basic HTTP service, or robust asynchronous messaging environment. For example, Tibco a traditional middleware vendor strong in the financial services, is competing with the dominant players and moving into the business process automation segment of this market. Oddly enough, I know of one large pharmaceutical company that is using Tibco's Business Works as an "interim" SOA solution, before deciding on IBM or BEA. This organization clearly underestimates Tibco's ability to become a major SOA platform.
In general, an SOA that utilize an ESB exposes a service as a proxy. As Figure 1 illustrates, communication from the client to the ESB or ESB to the business service can be over HTTP, JMS, SMTP, or FTP.
One way to determine which vendor(s) are appropriate for your organization is to know your Web services "system" Use Cases, such as:
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.
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:
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.
Develop a Service-Oriented Architecture Methodology
Use Spring Web Flow with IBM WebSphere Application Server 5
Use Enterprise Generation Language in a Service-Oriented Architecture
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.