ASPnews Home





ASP Directory


About Us

Search ASPnews:
Internet Lists
Internet News
Internet Resources
Linux/Open Source
Personal Technology
Small Business
Windows Technology
xSP Resources
Corporate Info
Tech Jobs
E-mail Offers
Be a Commerce Partner
Cheap Plane Tickets
Digital Camera Review
Register Domain Name
Memory Flash Cards
Online Education
Remote Access
Advertising Trucks
Online Degrees
Best Digital Camera
Cheap Web Hosting
Digital Camera Review

ASPnews Focus
Top News:
» SOAs So Close, Yet So Far

» Why SaaS Is Making a Comeback

» Join the Discussion:'s industry forums

» More ASP News

TOP 50
Top 20 Providers
 & Top 30 Enablers
Free Newsletter!

ASPnews Shortcuts
Week's Top News

ASP News at

Industry Events

Discussion Forums

Industry Basics

Site Guide

Why Choose Novell for Linux? Learn why Novell is the best distribution vendor for Linux from both a technology and support standpoint.


Migrating to a Service-Oriented Architecture, Part 2

Continued from Page 1

Addressing the Old Problems

Let’s return now to the first integration scenario discussed and the search for a scheme that minimizes the number of required interfaces, such as is drawn in Figure 2.

Figure 2. Minimizing interfaces

This might appear to be an overly simplistic view, but it should now be clear that, within a framework such as EWA, this view is the starting point. Now, add the architectural concept of the Service Bus, represented in Figure 3 by the heavy center line, and a service or flow manager to connect the services and provide a path for service requests. The flow manager processes a defined execution sequence, or service flow, that will invoke the required services in the proper sequence to produce the final result. The Business Process Execution Language, or BPEL, is an example of such a technology for defining a process as a set of service invocations.

Figure 3. Adding a Bus and execution management

From here, you would need to determine how to call the services, so you would add application configuration. Next, virtualize the inputs and outputs. Finally, provide connectivity to backend processes, thus allowing them to run as-is and migrate in the future. Now, the high-level picture is at least structurally complete, and looks like Figure 4.

Click here for a larger image.

Figure 4. Completing the basic structure

It should not be at all surprising that this picture bears some resemblance to a block diagram of EWA; at the highest level, any robust application framework must provide these functions. From here, however, the real work begins — building the 1,500 components that put flesh on this skeleton. This is why many IT architects choose to implement within an existing framework; the process of decomposing the existing applications into components for the framework is work enough, without reinventing all the other general-purpose and system components known to be needed.

However you approach it, you can implement the architecture using technologies and frameworks that exist today, and so you come full circle, back to the beginning, where the process starts with an analysis of the business problems that must be solved. You can do this now, confident in the knowledge that your architecture will be, in fact, implementable.

Page 3: Integration Requirements Within the Architecture

Go to page: Prev  1  2  3  4  5  Next  

Email this Article
View Printable Version
Back to Analysis


Featured Links
Learn the secrets of the popular search engines!
Free Web Hosting Buyer's Guide -- Click Here!
Enhance your Web site with the Dynamic HTML HierMenus Code

JupiterWeb networks:

Search JupiterWeb:

Jupitermedia Corporation has three divisions:
Jupiterimages, JupiterWeb and JupiterResearch

Copyright 2005 Jupitermedia Corporation All Rights Reserved.
Legal Notices, Licensing, Reprints, & Permissions, Privacy Policy.

Jupitermedia Corporate Info | Newsletters | Tech Jobs | Shopping | E-mail Offers

Give us your Feedback