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

LINUX IN THE ENTERPRISE: The Gartner Group’s George Weiss will share his insights about the state of Linux today. Join us on May 3rd, 2005 at 1 PM EST for this live Webinar.


Migrating to a Service-Oriented Architecture, Part 2

Continued from Page 2

Integration Requirements Within the Architecture

So far in this discussion, integration has been confined to application integration via component-based services, but integration is a much broader topic than this. When assessing the requirements for an architecture, several types or “styles” of integration need to be considered. You must consider the following:

  • Application integration
  • Integration at the end-user interface
  • Application connectivity
  • Process integration
  • Information integration
  • A build to integrate development model

Integration at the end-user interface is concerned with how the complete set of applications and services a given user accesses are integrated to provide a usable, efficient, and consistent interface. It is an evolving topic, and the new developments, for the near term, will be dominated by advances in the use of portal servers. While portlets can already invoke local service components via Web services, new technologies, such as Web Services for Remote Portlets, will enable content and application providers to create interactive services that plug and play with portals via the Internet, and thereby open up many new integration possibilities.

Application connectivity is an integration style concerned with all types of connectivity that the architecture must support. At one level, this means things such as synchronous and asynchronous communications, routing, transformation, high speed distribution of data, and gateways and protocol converters. On another level, it also relates to the virtualization of input and output, or sources and sinks, as you saw in EWA’s Channel and Protocol Handlers. Here, the problem is the fundamental way data moves in and out of, and within, the framework that implements the architecture.

Process integration is concerned with the development of computing processes that map to and provide solutions for business processes, integration of applications into processes, and integrating processes with other processes. The first requirement might seem trivial; that is, that the architecture allows for an environment within which the basic business problems can be modeled, but insufficient analysis at this level will spell doom for any implementation of the architecture, regardless of its technical elegance.

Integration of applications into processes might include applications within the enterprise, or might involve invocation of applications or services in remote systems, perhaps those of a business partner. Likewise, process-level integration might involve the integration of whole processes, not just individual services, from external sources, such as supply chain management or financial services that span multiple institutions. For application and process integration needs, technologies like BPEL4WS can be used, or the application framework can use a program configuration scheme such as the one seen in EWA. In fact, a higher-level configuration scheme can be constructed using BPEL4WS at a lower level, and then driven by an engine that provides more function than just flow management. Before any of this is built, however, you must first understand the architectural requirements, and then build the appropriate infrastructure.

Information integration is the process of providing a consistent access to all the data in the enterprise, by all the applications that need it, in whatever form they need it, without being restricted by the format, source, or location of the data. This requirement, when implemented, might involve adapters and a transformation engine, but typically it is more complex than that. Often, the key concept is the virtualization of the data, which might involve the development of a data bus from which data is requested using standard services or interfaces by all applications within the enterprise.

Thus, the data can be presented to the application regardless of whether it came from a spreadsheet, a native file, an SQL or DL/I database, or an in-memory data store. The format of the data in its permanent store might also be unknown to the application. The application is further unaware of the operating system that manages the data, so native files on an AIX or Linux system are accessed the same way they would be on Windows, OS/2, ZOS, or any other system. The location of the data is likewise transparent; because it is provided by a common service, it is the responsibility of the access service, not the application, to retrieve the data, locally or remotely, and then present the data in the requested format.

Lastly, one of the requirements for the application development environment must be that it takes into account all the styles and levels of integration that might be implemented within the enterprise, and provide for their development and deployment. To be truly robust, the development environment must include (and enforce) a methodology that clearly prescribes how services and components are designed and built in order to facilitate reuse, eliminate redundancy, and simplify testing, deployment, and maintenance.

All of the styles of integration listed above will have some incarnation within any enterprise, even though in some cases they might be simplified or not clearly defined; thus, you must consider them all when embarking on a new architectural framework. A given IT environment may have only a small number of data source types, so information integration might be straightforward. Likewise, the scope of application connectivity might be limited. Even so, the integrating functions within the framework must still be provided by services, rather than being performed ad hoc by the applications, if the framework is to successfully endure the growth and changes over time that all enterprises experience.

Page 4: Benefits of Deploying a Service-Oriented 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