Channels ▼


Enterprise Service Bus: Part 1

Service Architecture

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.

[Click image to view at full size]
Figure 2: System roadmap.


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

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.