HETEROGENEOUS MIDDLEWARE STRUCTURES FOR MYGROCER PROJECT Dr. Eugene A. Gryazin*, Prof. Juha O. Tuominen**, M.El.Eng. Olli Seppala*** Helsinki University of Technology, Department of Computer Science and Engineering, Interactive IT Laboratory, PL9700, 02015, Espoo, Finland *
[email protected] **
[email protected] ***
[email protected]
ABSTRACT This article analyzes and classifies different middleware platforms. A comparison of two popular middleware platforms, CORBA and Web Services (XML-SOAP), is presented. Also, an implementation of MyGrocer project (IST-2000-26239 MyGROCER) mediation service is described, highlighting its distributed architecture.
Keywords MyGrocer system, middleware, CORBA, Web Services, SOAP, XML, internetworking.
1. INTRODUCTION There is a considerable interest in Middleware (intermediate or interplatform software) within the distributed and mobile software community [9]. The market of these means has grown exponentially, and, by various estimations, the tendency will continue [6]. In this article, an attempt to solve the fundamental problems of using middleware within e- and m-commerce applications is presented. The term "intermediate software" (middleware) is well known, but at the same time it is quite often used ambiguously. From the general point of view, middleware is the software providing an API between the applications and the resources. Hence, many types and kinds of software simplifying the interaction of system components or services or resources can be called as “middleware”. Middleware carries out two basic functions. The first one simplifies the access of applications to resources. Such a function is important, first of all, for the developers of information systems as it allows them to focus on the development of the business logic, instead of developing various access and data distribution mechanisms. The second function of middleware is the acceleration of the interaction between software entities, or the entities and the data. Middleware as a standard solution is far more productive and easier to maintain than tailored solutions developed by individual designers.
2. CLASSIFICATION OF MIDDLEWARE 2.1 Classification of middleware facilities All middleware can be classified into one of the two following groups (fig. 1): 1) Middleware providing interaction between the active application (referring to an application, for example, implementing a business logic) and a passive resource (referring, for example, to a database server).
2) Middleware providing interaction between active applications. It should be noted that the given classification is not exhaustive, as it merely outlines the rough categories typically associated with middleware. For more details, please refer to [8]. 2.1.1 Middleware as a bridge between active and passive entities
The first group introduced above can be further divided into two basic subgroups: middleware for databases and monitors of transactions. Middleware for databases. Middleware for Database (DB) servers is the most widely-known and
M i d d l e w a r e
DB oriented
Transactions monitors
Application
DB
RPC
Application
MOM
ORB
Application
frequently-used form of intermediate software. Its major function is defining and implementing an Application Program Interface (API) for the access to the local or remote databases. Thus from the developer’s viewpoint, not only the features of the underlying operating system are hidden from the Figure 1. Middleware classification
application, but also the location of the database. Typical representatives of this type of middleware are ODBC, OLE DB and JDBC. Monitors of transactions. If the problem of interaction with the DB is solved by middleware, transaction-processing monitors (TP-monitors) optimize the overall system-level co-operation. TPmonitors settle down between the client and DB server forming the second layer of the three-tier architecture [9]. The basic advantage of transactions is that they allow "to issue" a part of the application as a transaction. A transaction differs from a simple sequence of commands in the integrity: provided that during its execution an error or another unrecoverable problem occurs, such as a denial of access to a resource, the TP-monitor automatically returns the call and lets the system continue the execution from a well-defined state. 2.1.2 Middleware for active applications
The second class of middleware providing interaction between active applications, as introduced earlier in section 2.1, can be conditionally divided to three basic types: middleware with remote calls of procedures (RPC, Remote Procedure Call), middleware with message transfers (MOM, Message Oriented Middleware) and middleware brokers of objective inquiries (ORB, Object Request Broker). RPC. RPC as introduced in the early 1980s was the first intermediate software, though at that time, it was not called middleware. RPC allows a part of an application to be executed transparently by a
remote machine. RPC code "joins" both applications – the source and the receiver – and carries out the necessary data transformations as well as handles the data transmission in the network. The problem with the early RPC applications was that the more operating systems and implementation languages they dealt with, the more complex and difficult they got to use. The modern RPC, on the contrary, allows the developer to operate on a higher level of abstraction independently of the platform. Thus, RPC became a convenient mechanism for handling the interaction between applications on various hardware and software platforms, especially for client-server mechanisms (fig. 2). RPC imposes certain restrictions on the communication between the applications. RPC communication is synchronous: after sending out a request, an RPC application is blocked until a reply is received. Should the reply be delayed or completely lost, the RPC application will fail. In practice, though an asynchronous RPC has been introduced, RPC is limited to low-latency connections, and is not practical within global networks, where delays and failures are very likely to occur. It is also to be noted that the distributed use of Java language called RMI (Remote Method Invocation) [3] and the widely used XML-based Simple Object Access Protocol (SOAP) [2,11] greatly resemble RPC.
Client process
Server process
client routines local procedure 1 call
server routines
10
client stub
server stub
9
system 2 call
6
5
7
4 8
network routines local kernel
network communications 3
network routines remote kernel
Figure 2. RPC-model interaction sequence
MOM. The next step in the development of middleware for application communications was message passing. The principle was simple, but effective: applications do not communicate directly, but send messages to each other via special buffers (turns). MOM provides the storage and delivery mechanisms for these messages between platforms and across different network protocols. MOM is similar to transaction monitors and can be used to optimize application interactions. MOM is intended for the transfer of the structured information between applications. ORB. Similar to MOM, ORB operates by exchange of messages in a network. Similarly a "human" broker, the ORB carries out functions of the intellectual intermediary, i.e. accepts inquiries from a client (client applications), carries out search and activation of remote objects which reply, and finally
transfers the reply message to the original requester. Like RPC and MOM, ORB abstracts the details of the communications from the requesting object as a name of the requested object with a few additional parameters. Interest in ORB is driven by the fact that it supports the object model which is becoming de facto standard in the development of large information systems. The main ORB players are the CORBA standard [3,7], Microsoft COM+/.NET technology, and J2EE (Java 2 Enterprise Edition) by Sun Microsystems [2,3]. Microsoft COM+/.NET. Despite the development of services for COM+ and, its successor .NET, these Microsoft platforms for distributed object applications are only accessible on the Windows platform. Due to proprietary standards, close integration with the Windows operating systems and the absence of alternative implementations, the applicability of COM+/.NET technologies to company infrastructures is limited.
Flexibility Adaptability
OMG CORBA [10]. The OMG (Object Management Group, http://www.omg.org) consortium has been developing CORBA (Common Object Request Broker Architecture) since 1989, as a
WebServices
CORBA J2EE AppServer
.NET DCOM
TPM MOM Proprietary Platform Specific
Open, Standard Heterogeneous
collaboration of leading experts from more than 800 companies and the organizations. Independent of programming languages and platforms, fundamental object orientation and many other unique Figure 3. Middleware deployment options [1]
characteristics have contributed to standardization which includes also aspects of interaction of implementations of CORBA from different suppliers. Java 2 Enterprise Edition (J2EE). The J2EE platform developed within the framework of JCP (Java Community Process) standardization has, for the first time, offered an integral component model called EJB (Enterprise Java Beans) focused on the creation of the server business logic. The use of CORBA architectural achievements in J2EE major services, down to a level of distributed interaction based on CORBA-IIOP (Internet Inter-ORB Protocol) [7,10], has provided excellent scalability in systems based on J2EE. The main characteristics of the most widely-used middleware technologies is presented in Figure 3.
3. MYGROCER DISTRIBUTED SYSTEM IMPLEMENTATION 3.1 Comparison of two state-of-the-art middleware platforms: CORBA and Web Services During the last decade, distributed technologies have become an important means of connecting the growing numbers of decentralized computing resources. Especially electronic and mobile commerce needs a stable, robust and at the same time very flexible complex platform. Internet technologies raise the potential of distributed processing and impose new requirements to existing applications seeking a role as tomorrow's Web-services. However, the diverse nature of operating systems, networks and programming languages makes distributed data processing into an expensive game with complicated interoperability questions. RPC is currently the most common means of communication in distributed systems, opportunities for allocating separate parts of applications in an iterative, componential architecture remain limited. Microsoft’s .NET initiative supported with SOAP, is aimed at simplifying RPC functionality and providing interoperability through the use of XML. CORBA technology offered by OMG is the standard of interoperability software for corporate distributed computing environments, is especially on Unix-systems and mainframes [10]. OMG has worked very hard to adapt the CORBA architecture to the requirements of real systems, but has not won favor with developers. Modern technologies should correspond to specifications of the latest standards, and customers will determine whether SOAP can become the successor CORBA as a corporate model of distributed processing. SOAP is the intermediate link in simplifying communication of distributed object-oriented applications and providing them normal interaction irrespective of a platform for which they are written. Correctly speaking, it is impossible to compare CORBA to SOAP directly. SOAP is the protocol part of the RPC mechanism (as mentioned above). The corresponding part of CORBA is IIOP, so it is possible to compare SOAP and IIOP, but CORBA is much bigger than IIOP/GIOP. Table 1 shows the correspondent structure of Web Services levels to CORBA levels. Table 1. Layer levelling in CORBA and Web Services
Level
Web Services [2,11]
CORBA [3,10]
Protocol
SOAP, HTTP, XML
IIOP, GIOP
Location identifiers
URL
IOR, URL
Interface spec
WSDL
IDL
Naming, directory
UDDI
Naming Service, Interface Repository, Trading service
There are quite a few issues with Web Services (SOAP) and CORBA. The main features of the compared platforms are described below. 3.2 CORBA First OMG document release was published in 1991, OMA (Object Management Architecture) Guide - the guidebook to the architecture of object management, describing the core of CORBA. In 1992 its advanced variant has issued, and in 1994 CORBA 2.0 was released. At this point it became obvious that the standard was viable and exists now in the excellent form. CORBA consists of 4 basic parts (http://www.omg.org/technology/documents/spec_catalog.htm): •
Object Request Broker;
•
Object Services;
•
Common Facilities;
•
Application and Domain Interfaces.
Client - server and object concepts are the two main points in CORBA ideology. In CORBA space the object becomes the intellectual program unit, an independent component - part of a program code with the following features: •
The component may become a subject of sale and purchase in the market of software;
•
The component in itself is not the application;
•
The component may be used in such conditions which the programmer who has developed it in any way might not foresee;
•
The component does not depend on address space, network protocol, algorithmic languages, operation systems, specific infrastructures;
•
The component has an advanced interface.
Components are objects that support inheritance, polymorphism and encapsulation. Components are base elements of the ORB. Each provides a certain type of service, for example, access to a database, accounting postings, the account of the goods. The fascinating idea - to build applications of components, is as simple as a small house from the LEGO. This idea is realized in CORBA. OMG has developed a special top-level language for describing ORB and other CORBA components IDL (Interface Definition Language). IDL is unusual as it only contains descriptions, declarations, passive definitions of attributes, parental classes, types of supported events, methods, basic and compound types of the data, exclusive situations for processing mistakes, but no direct functionality. IDL describes interfaces the same way that classes do in C++ or in Smalltalk, interfaces in Java, and packages in Ada95. Each interface defines operations which may be requested by clients, but not operations are carried out outside of IDL and CORBA. IDL syntax is a subset of C++ with additional keywords for support of the distributed concepts. IDL compilers exist for many different programming languages.
One of tasks of the OMG is the “IDL-isation” of all client-server applications that interact through ORB and support dynamic and static interfaces. The first is defined during application development, the second is designed at runtime on the working application. Another "interface" definition for CORBA is "the standard for intermediate software which supports both static and dynamic methods of a call ". Figure 4 shows the client and server parts of ORB. Figure 4. Structure of simple CORBA
Object Implementation (server)
CLIENT
Interface Repository Dynamic Invocation Interface
Client IDL stubs
ORB Interface
Dynamic Static Invocation Skeletons Interface
Interface Repository
Object Adapter
O R B Client IDL Stub - connects client applications with ORB. Written in IDL after client compilation the client stub becomes transparent for the client-object becomes a proxy to the remote server-object. The Server IDL Stub or Static Skeletons similar to the Client IDL Stub connecting the ORB and server applications. The interface of a dynamic call is created after IDL compilation. The Dynamic Invocation Interface allows the client object to create searches in real time, the structure of search, parameters and attributes and even the link to the destination object are generated in DII (Dynamic Invocation Interface) or from data received from Interface Repository. The Dynamic Skeleton Interface is the server analog of DII. The ORB Interface is the logic interface which carries out auxiliary functions, such as converting links to the server-object, creating the argument list for searches made through the dynamic interface etc. The Object Adapter deliverys searches to the serverobject and it’s activation if necessary. The Interface Repository is a realtime database of all registered interfaces with methods and parameters they support. All IR data are accessible and modifiable by components. CORBA has a number of standard object services such as: •
Naming, enables system components locate each other in a distributed environment.
•
Events, an object may dynamically subscribe to an event of other object and will get notified when it has occurred. The service creates a special object (the channel of events) which collects and notifies based on events among the interested objects.
•
Security, controls access rights in the distributed environment.
•
Transactions, for use with databases for confirmation or "roll back" for all changes made on ORB.
•
Trading, an alternative to the Naming service. Instead of the linking to the necessary object by name, it enables the sending object to choose a group of objects of the requested type.
•
Life Cycle, allows the creation, coping, moving and destruction of ORB components.
•
Externalisation, import/export service – allows storing an object’s internal parameters in a textual file permitting duplication or restoration of the object.
•
Licensing, prevents non-authorized use of program components in the distributed environment.
•
Time, a set of interfaces for setting the current time and operations and events with time intervals.
•
Property, for attributing properties to objects. Necessary when an application may not assign the necessary properties through the mechanism of attributes and operations in a distributed object environment, not mentioning IDL definition.
•
Relationships, for connecting objects through IDL definitions.
•
Concurrency Control, a coordination service, which protects system in case of sharing the same data by defining ways of blocking access to the data.
•
Persistent Objects, service of reliable storage - data which should be kept in the protected structures.
•
Query, a search service, defines a data set and query methods within that set. Supports most query languages, especially SQL.
3.3 Web Services According to architecture specialist Mark Colan from IBM, Web-services are "module Internets applications carrying out specific business - tasks and appropriate specific technical format". Thus, if certain processes of the application can be directed via the Internet by methods in a standard format, it is already a Web-services server. On the other hand, if the application invokes external processes through the Internet, it is a client of Web-services. Implementation of such an open architecture is only possible through standardized formats and methods. This is the reason for the proposed SOAP (Simple Object Access Protocol or as ServiceOriented Architecture Protocol) - protocol for remote procedure call (RPC-protocol, as mentioned previously) using standard information interchange protocols of the Internet: HTTP for synchronous calls and SMTP for asynchronous. SOAP uses XML as a format of the description and data exchange. SOAP is based exclusively on reliable standards, and has received wide recognition from companies such as Microsoft, IBM, Oracle and Sun. Moreover, it is the basis of Microsoft’s .NET and has the advantage of the implementations being based on open source code. SOAP does have limitations as it is only the low-level RPC-protocol and leaves much to developers. To simplify the use of SOAP, WSDL (Web Service Description Language) was created. WSDL can be considered as an addition to SOAP as it implements interaction between Web-services. As CORBA IDL acts as a CORBA descriptor of services, WSDL is the XML-syntax describing Web-services. With WSDL, SOAP applications, may independently adjust the interaction of Web-services, hiding most of the low-level operations. The minimum necessary to use a web service is as follows: To find suitable partner (who provides the required Web-services); •
To receive the necessary information for opening communications with the partner (for example to address to the WSDL-document).
This is UDDI (Universal Description, Discovery and Integration). Independent of platforms and with a completely open technical architecture, it will allow enterprises to find each other in order to mutual communication schemes through the Internet and to negotiate information sharing by means of the World Registration System.
Thus, the technical circuit which can be built for Web-services includes: •
XML - a format of the description and data exchange;
•
SOAP - the protocol of a call of Web-services;
•
WSDL - a format of the description of Web-services;
•
UDDI - the centralized body of registration, search and use of Web-services.
Basically, SOAP/WSDL/UDDI (Web-services) is the latest in RPC technologies, but here is what SOAP isn't: •
It isn't object oriented - it is procedural;
•
It isn't simple - it requires an understanding of XML, including XML namespaces;
•
It isn't lightweight - it needs XML generators/parsers on client and server sides, and just sending a one-byte character of payload can use 1000 bytes of message;
•
It isn't a complete RPC system.
3.4 Results CORBA is very attractive to developers. OMG has put a lot of effort in to providing compatibility in CORBA with new protocols, and as a side effect, links have appeared to open-source projects for mechanisms to transform SOAP inquires to CORBA calls. In the field of Web-services, CORBA has certain advantages over the plain linkage of programming languages and API-interfaces. While the CORBA IDL represents the mechanism of the interface description syntax, a similar role is carried out by WSDL, used at construction of Web-services. Even more important is CORBA’s support of componential development and enterprise applications integration (EAI), providing requirements for interaction in natural terms of objects. In the foreseeable future, CORBA remains the best of it’s kind. The architecture remains the best for the execution of large-scale projects that emphasize productivity, robustness and reliability. At the same time, SOAP improves interaction of components operating on various platforms in cases where access to Internet and simplicity of expansion play a key role. As processor and network capabilities improve, many of the limitations of SOAP are reduced, making this technology ideal for a wide range of projects at the corporate level. Both Web Services (SOAP), and CORBA occupy the same niche in the field of the distributed applications. Therefore only the basic features are featured in the comparison of the two technologies in table below (Table 2). Table 2. Main features of Web Services and CORBA
Web Services (SOAP)
CORBA
Integrating message passing and RPC CORBA specifications already have a well functionalities requires an additional interface integrated interface and support complex software layer. interactions and inherited interfaces. SOAP is accessible to programmers on Visual The CORBA architecture requires significant Basic, with minimal retraining due to simplicity effort in learning and use. Its scope, as a rule, is in development and application technology limited to large-scale projects Access to SOAP components via HTTP through gateway screens and Web-servers. Thus simplifying the integration of business-tobusiness (B2B) applications.
CORBA needs open connections to a network. The use of gateway screens may cause complications. Full-function implementation of similar technologies are practical only on dedicated servers.
Text communications in SOAP are effective for Binary
communications
in
CORBA
gives
the information transfer, but need higher increased speed in data transfer and processing bandwidth, and require parsing by the client side As SOAP is based on XML, interoperability CORBA is also based on open specifications, between various platforms becomes simpler needs the coordination of configurations of various brokers of object searches SOAP specifications are not yet fully CORBA is not fully Internet oriented, but work is standardized, so early adopters will need to progressing and gradually it becomes more and modify their code when the standard is finalized more adapted to teamwork with SOAP and Webservices [4] SOAP security specifications are under work, Specifications of CORBA security already exist but have not been finalized. Security mechanisms have been adopted from HTTP only.
3.5 MyGrocer platform implementation As mentioned before [5], the mediation server platform in MyGrocer e-shopping system has many services and integrates a set of built-in Servers, both internal and external. Having many different servers, many different functionalities and properties are required. Internal servers providing for internal enterprise clients need robust and stable connections with state-keeping policies and “follow by” service-oriented mechanisms. Main features for external servers are interoperability and data format independence. Inspection of the two in terms of middleware platform criteria, it can be seen that the two examined platforms fit the requirements, exactly. The mediation platform architecture according to this description and following the MyGrocer concept is shown in Figure 2.
All clients connect to corporate servers and are behind firewall systems with robust CORBA oriented client software, simplifying administration and allowing a state oriented approach for client services. Externally (beyond the firewall) in open Internet space, it is better to use the Web Service approach, which gives Server administrators confidence and channel control with simple deployment for new proposed services.
Figure 4. Structure of MyGrocer distributed mediation platform
The lightning-shaped objects in Figure 4 represent wireless connections. The servers included in the mediation platform deliver the connectivity services (dial-up etc.), through which the clients can
connect to the service via CORBA (i.e. Server1). Access to MyGrocer services via public networks is based on SOAP.
4. CONCLUSION AND RESULTS This paper presented an analysis and comparison of the most commonly used middleware platforms. As an example of the potential of mixed use of various middleware technologies, it also presented the architecture the mediation platform of the MyGrocer project having the following advantages: - CORBA is used for distributed corporate networks as a powerful and universal middleware solution - Web Services (XML/SOAP) is used for interplatform interaction and is easily accessible from extranet -
All documents in B2B and B2C models use a universal XML-oriented approach
-
All intracorporate interactions are significantly fast and secure, due to CORBA
-
While protected by firewalls, the network is transparent for the customers
- A group of major companies (IONA, Rogue Wave, Borland, HP, Sun, Microsoft) support both CORBA platform as well as the tools for building interoperability between the different platfomes -
The standardization process for CORBA-SOAP interaction is practically completed
REFERENCE 1. Borland corp., Implementation Infrastructure: enablers for Rapid Enterprise Integration. OMG Information Days 2002, Enterprise Application Integration with Model Driven Architecture, Helsinki, 5 March 2002 2. Brogden, B. SOAP Programming with Java. San Francisco, London: SYBEX, 2002. 3.Brose, G.; Vogel, A.; Dubby, K. Java Programming with CORBA. New York, Chichester, Wienheim, Brisbane, Singapore, Toronto: John Wiley & Sons, Inc., 2001. 4. CORBA Web Services. Initial Joint Submission. (ftp://ftp.omg.org/pub/docs/orbos/01-06-07.pdf) 5. Gryazin, E. A., and Tuominen, J. O. “SMART” Environment for Easy Shopping. Proceedings International ITEA Workshop on Virtual Home Environment, February 20-21, 2002, 103-111. 6. McCoy, D. Application Integration and Middleware at the Crossroads, Gartner Group Article top view, AV-15-1027, (19 December 2001). 7. Mowbray, T.J., and Malveau, R.C. CORBA Design Patterns. New York, Chichester, Wienheim, Toronto, Singapore, Brisbane: John Wiley & Sons, Inc., 1997. 8. TechWeb business technology network. Network computing web site. On the Web: Middleware vendors and products. (http://www.networkcomputing.com/netdesign/cdmwprod.htm) 9. TechWeb business technology network. Networkmagazine.com. Tutorial – Lesson 134: Middleware by Jonathan Angel. (http://www.networkmagazine.com/article/NMG20000425S0003) 10. Wallnau, K. Common Object Request Broker Architecture. Technology Review. Carnegie Mellon Software Engineering Institute. (http://www.sei.cmu.edu/str/descriptions/corba.html) 11. Web Services. Technical overview. Sun Microsystems (http://dcb.sun.com/practices/webservices/overviews/overview_soap.jsp)
web
site.
