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

Case Study: Aria Systems Chooses Oracle to Keep IT Costs in Check.


The Case for Developing a Service-Oriented Architecture, Part 1

Continued from Page 2

And What of the Future?

Over the last four decades, the practice of software development has gone through several different programming models. Each shift was made in part to deal with greater levels of software complexity and to enable the assembly of applications through parts, components, or services. More recently, Java technology contributed platform-neutral programming, and XML contributed self-describing, and thus platform-neutral, data.

Now, Web services has removed another barrier by allowing the interconnection of applications in an object-model-neutral way. Using a simple XML-based messaging scheme, Java applications can invoke DCOM-based, CORBA-compliant, or even COBOL applications. CICS or IMS transactions on a mainframe in Singapore can be invoked by a COM-based application driven by Lotus Script running on a Domino server in Munich. Best of all, the invoking application most likely has no idea where the transaction will run, what language it is written in, or what route the message may take along the way. A service is requested, and an answer is provided.

Web services are more likely to be adopted as the more genuine standard to deliver effective, reliable, scalable, and extensible machine-to-machine interaction than any of its predecessors, as a result of the timely convergence of several necessary technological and cultural prerequisites. These include:

  • A ubiquitous, open-standard, low-cost network infrastructure, and technologies that make for a distributed environment much more conducive to the adoption of Web services than both CORBA and DCE faced
  • A degree of acceptance and technological maturity to operate within a network-centric universe that requires interoperability to achieve critical business objectives, such as distributed collaboration
  • Consensus that low-cost interoperability is best achieved through open Internet-based standards and related technologies
  • The maturity of network-based technologies (such as TCP/IP), tool sets (IDEs, UML, and so forth), platforms (such as J2EE platforms), and related methodologies (such as OO, services, and so on), that provide the infrastructure needed to facilitate loosely-coupled and interoperable machine-to-machine interactions — a state far more advanced than what CORBA users experienced.

Service-oriented architectures allow for the design of software systems that provide services to other applications through published and discoverable interfaces, and where the services can be invoked over a network. When you implement a service-oriented architecture using Web services technologies, you create a new way of building applications within a more powerful and flexible programming model. Development and ownership costs as well as implementation risks are reduced. SOA is both an architecture and a programming model, a way of thinking about building software.

On the horizon, however, are even more significant opportunities. First, there is Grid computing, which is much more than just the application of massive numbers of MIPS to effect a computing solution; it also will provide a framework whereby massive numbers of services can be dynamically located, relocated, balanced, and managed so that needed applications are always guaranteed to be securely available, regardless of the load placed on the system.

This, in turn, makes obvious the need for the concept of on-demand computing, which might be implemented on any configuration, from a simple cluster of servers to a network of 1024-node SP2s. The user needs to solve a problem and wants the appropriate computing resources applied to it – no more, no less – paying only for the resources actually used.

The effective use of these new capabilities will require the restructuring of many existing applications. Existing monolithic applications can run in these environments, but will never use the available resources in an optimal way. This, along with the problems previously discussed, leads to the conclusion that a fundamental change must be made — the conversion to a service-oriented architecture.

Page 4: Requirements for a Service-Oriented Architecture

Go to page: Prev  1  2  3  4  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