Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
The Emerging Role of the Web for Enterprise Application and ASPs

The Emerging Role of the Web for Enterprise Application and ASPs

Ratings: (0)|Views: 28|Likes:
Published by Deep

More info:

Published by: Deep on Sep 19, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





The Emerging Role of the Web for EnterpriseApplications and ASPs
 Invited Paper 
Web technologies were initially used for Web publishing and ad-vertising in enterprises. However, over the years Web technologieshave merged with other distributed computing technologies and assumed a vital role in satisfying enterprise business needs. This paper takes a systematic and practical look at Web evolution fromstatic HTML to Web-enabled business components that are at the foundation of currently popular Web services (WS). In particular,WSisaresultofconvergenceoftheWebwithdistributedobjecttech-nologies and is positioned to play a central role in building and in-tegrating enterprise applications in the future. However, the impact ofWS is not limitedto enterprise boundaries—business-to-businesstrade and outsourcing through application service providers canalso be profoundly impacted. This paper highlights the key aspectsofthesedevelopmentsbecausetheywilldrivetherequirementstobesatisfied by the current and future Internet technologies. The pos-sible deterrents to these developments and approaches to addressthese deterrents are also discussed.
 Application service providers (ASPs), common ob- ject request broker architecture (CORBA), distributed computingobject model (DCOM), distributed objects, enterprise applicationintegration (EAI), Extensible Markup Language (XML), object re-quest broker (ORB), service-oriented architectures (SOAs), SimpleObject Access Protocol (SOAP), universal description, discovery,andintegration (UDDI), Web applications, Web services (WS), WebServices Description Language (WSDL).
I. I
Web technologies have taken a central place in currentand future enterprise applications. Initially used for Webpublishing [i.e., building Web sites through static Hyper-Text Markup Language (HTML)], Web technologies haveevolved into a “Web tier”
that is used as an integrationglue between front-end and back-end applications and is at
Manuscript received October 14, 2003; revised March 17, 2004.The author is with Fordham University, New York, NY 10023 USA(e-mail: umar@amjadumar.com).Digital Object Identifier 10.1109/JPROC.2004.832955
The term “tier” is used in this paper to represent a logical instead of aphysical entity such as a hardware device.
the foundation of current application platforms such as Mi-crosoft’s .NET and Sun’s Java 2 Enterprise Edition (J2EE).Most current and future enterprise applications are beingdeveloped and integrated by using Web technologies, espe-cially Web services (WS)—a result of convergence of Webwith distributed object technologies [1]–[4]. In addition, Web technologies have enabled innovative business-to-busi-ness (B2B) trade and outsourcing models where applicationservice providers (ASPs) can host a wide range of servicesby just providing a Web interface at the customer site. Forexample, a WS-enabled payment system in Singapore canwork with a WS-enabled shopping cart in New York and aWS-enabled inventory manager in London, U.K., to supporta global online purchasing system.Acceptance of Web technologies to build enterprise appli-cations has gone through several generations of evolutionsthat range from simple HTML to business componentssuch as WS. This evolution, as shown in Fig. 1, is a resultof convergence between the Web and other distributedcomputing technologies. The first-generation Web appli-cations were developed in the early 1990s by using thebasic Web technologies such as HTML, HyperText TransferProtocol (HTTP), Web browsers, Web servers, and commongateway interface (CGI). Many simple applications stilluse this model for Web advertising by fetching and dis-playing HTML pages. These applications also employ theclient/server model to access non-Web information (infor-mation stored in a database or back-end application)—thisis done by using CGI-based “Web gateways” that invokeremote procedure calls (RPCs) or remote Structured QueryLanguage (SQL) for accessing remotely located resources.The second-generation Web applications started using dis-tributed object technologies such as the common objectrequest broker architecture (CORBA) and the distributedcomputing object model (DCOM) for development of moresophisticated applications. In addition, Web server-sidedevelopment based on servlets and server pages (e.g., Javaserver pages (JSPs) and active server pages—ASPs) became
0018-9219/04$20.00 © 2004 IEEE
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 16, 2009 at 19:09 from IEEE Xplore. Restrictions apply.
Fig. 1.
Evolution of Web applications.
popular at the same time. The third and current generationof Web applications are taking advantage of developmentsin semantic Web [40], [50], with its emphasis on the Exten- sible Markup Language (XML) and components, to buildmission-critical applications.This paper takes a practical look at Web evolution to itscurrent status with particular emphasis on distributed objectsandWS.Thisdiscussion(SectionsIIandIII)isimportantbe-cause it symbolizes the merging of powerful technologies toserve business needs through the Internet
the main spirit of thisSpecialIssue.Inparticular,thispaperhighlightsdifferentaspects of enterprise applications with emphasis on the roleof WS and service-oriented architectures (SOAs) in enter-prise applications (Section IV), application integration (Sec-tion V), B2B trade (Section VI), and ASPs (Section VII).This perspective is important, because proliferation of WScan have a profound impact on the way the Internet will beused and will drive the requirements to be satis
ed by thelower layer Internet technologies. The paper concludes byoutlining the main issues that could deter widespread adop-tion of WS and pointing to possible approaches.II. F
Distributed objects are objects that are dispersed acrossthe network and accessed by remote users. An object on onemachine can send messages to objects on other machines;thus, a user can view the entire network as a collection of objects. Support of distributed object-based applicationsrequires special-purpose middleware that allows remote ob- jects to locate, bind, and communicate with each other [14],[32]. A common mechanism used by such middleware isan object request broker (ORB) that is responsible for theseoperations. Examples of middleware for distributed ob- jects include CORBA from the Object Management Group(OMG), DCOM from Microsoft, and Remote Method Invo-cation (RMI) from Sun Microsystems. Although the exactimplementations vary, they all follow the conceptual viewpresented in Fig. 2.
Each remote object that wishes to provide a servicede
nes it through an Interface De
nition Language(IDL). For example, purchasing and inventory appli-cations are represented as objects that advertise theirservices through IDL1 and IDL2, respectively (see
A Sample Abstract IDL for Inventory Management
below). IDLs are at the core of distributed objectapplications. Simply stated, an interface speci
es theapplication program interface (API) that the clientscan use to invoke operations on objects. In particular,an interface describes: 1) the set of operations that canbe performed on an object and 2) the parameters (inputand output) needed to perform the operations.
The ORB is the main bus that connects remote ob- jects with each other. It relies on a variety of 
to locate the objects (a directory), pro-vide security, support transaction processing, andcreate/delete instances of objects when needed (lifecycle support). For example, the ORB in Fig. 2 locatesIDL1 for purchasing and IDL2 for inventory checkingand then invokes the appropriate objects that providethese services.
A Sample Abstract IDL for Inventory Management
interface inventory /* interface name is inventory */ query_inventory (/*The operation to query inventory */ in char item_id; /* input is item id */ out integer on hand; /output is on hand */ out integer status) /* output status */ update price (/*The operation is to update price */ in char item id; /* input parameter is item -id */ in integer new price; /* input: new price */ out integer status) /*output parameter */ While distributed object computing provided a basicframework for building enterprise-wide distributed appli-cations, it did not succeed for B2B or global applicationsbecause the technologies were not well integrated withthe Internet. For example, CORBA relied on its own pro-tocol
Internet Interoperable Protocol (IIOP)
to commu-nicate between CORBA clients and CORBA servers. Thus,a CORBA client could not communicate with a CORBA
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 16, 2009 at 19:09 from IEEE Xplore. Restrictions apply.
Fig. 2.
Conceptual view of distributed object middleware.
server that was behind a corporate
rewall without the
re-wall being programmed to allow IIOP traf 
c. In other words,implementation of ORBs across organizational boundariesturned out to be a challenge.
The attention has lately shiftedto
business objects
essentially, largeobjects containing business functionalities
that could bedirectly accessed over the Internet. In these cases, as we willsee, the Internet and the Web assume the role of the ORBproviding the services for locating, binding, and communi-cating between remotely located business components.A component, according to Herzum and Sims [16], is
a self-contained piece of software that has a well-de
nedinterface and can be developed, delivered, installed, andrun independently.
Components are conceptually similarto objects that can be used independently, can be combinedto build applications, and can plug into the infrastruc-ture through sockets.
For example, Microsoft Draw is acomponent within Microsoft applications. This particularcomponent is high level enough to perform end-user typefunctions (it draws boxes, arrows, circles, etc.). It also workswith other components of the Microsoft Of 
ce Environment.Many desktop tools in the Microsoft Of 
ce Environmentare currently available as components. Examples of typicaldesktop components are spell-checkers, format painters,calendars, print managers, etc. Conceptually, each icon onyour toolbar can be a separate component.These components can be combined to build applications(you could
nd the same spell-checkers in MS Word aswell as PowerPoint). and can plug into the infrastructureenvironment such as Microsoft DCOM/COM+. In addi-tion to Microsoft DCOM/COM+ components, several Javacomponents, known as
Java beans
, are also commerciallyavailable to display clocks, calendars, etc., particularly inUnix/Linux environments. The components can exist at
As a personal experience, I managed several CORBA projects in the late1990s, and the problems of handling
rewalls and interbusiness ORBs be-came a major deterrent to project success.
Strictly speaking, objects have properties such as inheritance and poly-morphism, but components relax these restrictions [4].
several levels. Our interest is in
business components
thatimplement a single business concept, such as purchasing,payment, billing, etc. A business component usually consistsof one or more primitive components and can be distributedacross machines to satisfy business needs (see [9], [16], and [17]).Business components can be
Web enabled 
to providehighly reusable business services to Web users. This is themain idea of WS, also known as XML WS, which we willreview in the next section. In addition, platforms based onopen standards to support WS have become commerciallyavailable. For example, Microsoft
s .NET is an implemen-tation that is based on the WS speci
cation, and Sun
sJ2EE conforms to WS.
Fig. 3 shows a conceptual compo-nent-based architecture platform that is a generalization of the Sun J2EE, WS, and Microsoft .NET. This architectureis composed of several components that can exist at thefollowing tiers.
Client-tier components run on the client machine andcan represent a Web browser or another application.
Web-tier components run on the Web server to provideserver side support.
Business-tier components typically run on server ma-chines or minicomputers and are the business compo-nents because they represent business logic.
Resource (also known as enterprise)-tier softwaretypically runs on the back-end systems, such asmainframes.III. WS
The main idea of WS is quite simple
combine Web anddistributedobjectsintoasingleframeworkwheretheuser-to-component as well as component-to-component interactionsare conducted by using standard Web technologies. WS isconceptually the same as distributed objects but is based on
For more information about J2EE and .NET, see the Web siteshttp://www.sun.com and http://msdn.microsoft.com, respectively.
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 16, 2009 at 19:09 from IEEE Xplore. Restrictions apply.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->