The Power of it survival Guide for the cio
Download 1.93 Mb.
|
- Navigate this page:
- Basic Middleware Services
- Advanced Middleware Services
- Middleware Technologies
- Application Frameworks
- Application Servers
MiddlewareMiddleware is the term used for common, business-unaware services that enable applications to interact, usually across a network; the term is used to designate separate products that serve as the glue between two applications. Middleware is sometimes called plumbing as it connects two sides of an application and passes data between them. Basic Middleware ServicesThe basic middleware services can be listed as follow:
Client/Server Connectivity - Middleware provides the mechanisms by which network applications communicate across a network. For database networking for example, this includes the service of putting packages of query results data in network transport packets. This session layer interaction can also have its own timers and even error control to handle automatic retransmission of lost packets. One common feature is the ability for the client to interrupt the current operation on the server to cancel a large query response download. Platform Transparency - Client and server do not need an intimate knowledge of each other in order for work to be done. Differences between platform encoding like EBCDIC, ASCII and UNICODE are typically hidden by middleware. Middleware often runs on a variety of platforms, letting the organization use all its hardware platforms as required. Network Transparency - Middleware often makes networking choices transparent to application programmers. In reality, every middleware product runs on TCP/IP. Application and Tool Support - Before middleware can be used, it must present its own Application Programming Interface (API) to client applications that could use it. For shrink-wrapped tools like a database query tool, the API support can be critical. Language Support - Middleware should provide transparency across different SQL database dialects. Outside the database specific middleware products, generic middleware products often allow different programming languages to be used to create the distinct pieces of an application (pieces that reside on different machines). Database Support - In the area of database networking, middleware also provides a level of transparency across different data storage formats. It will make different RDBMSs look like the same RDBMS. A common way of solving this transparency is Open Data Base Connectivity (ODBC), a standard database access method developed by Microsoft. The goal of ODBC is to make it possible to gain access to any data from any application, regardless of which database management system (DBMS) is managing the data. ODBC manages this by inserting a driver, between the application and the DBMS. The purpose of this layer is to translate the application's queries into commands that the DBMS understands. Another solution is Java Database Connectivity (JDBC), a Java API that enables Java programs to execute SQL statements. This allows Java programs to interact with any SQL-compliant database. Since nearly all RDBMSs support SQL, and as Java itself runs on most platforms, JDBC makes it possible to write a single database application that can run on different platforms and interact with different DBMSs. JDBC is similar to ODBC, but is designed specifically for Java programs, whereas ODBC is language-independent. There are four different types of JDBC drivers:
Advanced Middleware ServicesBesides the basic services, middleware products can also offer more advanced services:
Single System Login - Many database connectivity solutions lack a separate authentication service. Without any security service tied into an organization-wide directory service, users have to log into each server separately. This means they will either forget usernames and passwords or they will breach security by keeping a list of everything on paper taped on their monitor. This situation also forces the database administrators to add a username and password to each server independently. More advanced middleware solutions let the user log in once to the middleware's security, which in turn handles authentication from there on. That security can or cannot be the same system used in a file and print environment. Enhanced Security - Some middleware vendors have security options much better than just usernames and passwords; support of smart card or biometric solutions and encryption are some examples. Location Transparency - Simple middleware solutions do not offer a name service. If the user wants to connect to a server and cannot remember the name of it, they will have to call the helpdesk. Advanced middleware solutions offer centralized naming services with some level of distribution. The issues are the same as those associated with DNS on the Internet. Database Services - In the database connectivity world, other services can be offered by middleware. An example is heterogeneous join support; if the middleware does a multi-RDBMS join transparently, then the client itself does not have to worry about the problems of handling differences and enhancing performance. Transaction Monitoring - In computing jargon, a transaction means a sequence of information exchange and related work (such as database updating) that is treated as a unit for satisfying a request and for ensuring database integrity. For a transaction to be completed and database changes to be made permanent, a transaction has to be completed in its entirety. A typical transaction is an order placed by a customer and entered into a computer by a customer representative. The order transaction involves checking an inventory database, confirming that the item is available, placing the order, and confirming that the order has been placed and the expected time of shipment. If we view this as a single transaction, then all the steps must be completed before the transaction is successful and the database is changed to reflect the new order. If something happens before the transaction is successfully completed, any changes to the database must be tracked, so that they can be undone. When a transaction completes successfully, database changes are said to be committed; when a transaction does not complete, changes are rolled back. Transactions must have the so-called ACID properties (ISO/IEC 10026-1:1992):
A program that manages the sequence of events that are part of a transaction is called a Transaction Monitor or TP monitor. A TP monitor must coordinate transaction control over a network and maintain the data consistency, even if a network or system failure occurs. Imagine there are five participating nodes at different places and a network failure occurs, the TP monitor will send a signal to all the nodes to be ready to commit or rollback (known as Prepare Phase), if all the five nodes in return send a yes to commit (known as Commit Phase) to the server then the distributed transaction is committed. If one node in return sends a rollback signal then the whole transaction is rolled back. This mechanism is known as two-phase commit. Application-to-Application Integration – Three different mechanisms can be used for application-to-application integration: message queuing, component buses and peer-to-peer communication. Message queuing is an asynchronous method to integrate different systems. There are two forms: Point-to-Point and Publish-and-Subscribe.
Message queuing provides a loose coupling of systems with a high level of scalability and availability. It allows load balancing and prioritization of messages. It affects the application design and is not suited for all types of applications. Components are pieces of software that are modular, have a well-defined and documented interface, are callable from any language, are disconnectable and replaceable and are distributable. A complete system can be assembled making use of components: user-interface components, business components, database components etc. Assembling is done using a Component Bus, which can reside physically on one machine, or be distributed over several machines. An alternative solution to message queuing and component buses is Peer-to-Peer (P2P). If message queuing is like the e-mail system, then Peer-to-Peer can be compared to the telephone system. P2P is a synchronous mechanism. Middleware TechnologiesMiddleware is realized on the Distributed Object Computing paradigm. In object-oriented computing every system component is seen as an object. An object not only has a data structure but also includes the methods that allow it to change its state. Objects can only communicate with the external world and with one another using messages. Distributed object computing extends an object-oriented programming system by allowing objects to be distributed across a heterogeneous network. The most popular distributed object paradigms are Microsoft’s Distributed Component Object Model (DCOM/COM+), OMG’s Common Object Request Broker Architecture (CORBA) and JavaSoft’s Java/Remote Method Invocation (Java/RMI). DCOM/COM+ is the distributed extension to COM (Component Object Model) that is why it is sometimes called “COM on the wire.” A COM server can create object instances of multiple object classes. A COM object can support multiple interfaces, each representing a different view or behaviour of the object. An interface consists of a set of functionally related methods. A COM client interacts with a COM object by acquiring a pointer to one of the object's interfaces and invoking methods through that pointer, as if the object resides in the client's address space. COM specifies that any interface must follow a standard memory layout. Since the specification is at the binary level, it allows integration of binary components possibly written in different programming languages such as C++, Java and Visual Basic. COM+ became available with Windows 2000 and is a complete standard. The fact that it is a Microsoft only standard can be seen as a disadvantage. CORBA [16] is a distributed object model proposed by a consortium of more than 700 companies called the Object Management Group (OMG). The core of the CORBA architecture is the Object Request Broker (ORB) that acts as the object bus over which objects transparently interact with other objects located locally or remotely. CORBA relies on a protocol called the Internet Inter-ORB Protocol (IIOP). A CORBA object is represented to the outside world by an interface with a set of methods. A particular instance of an object is identified by an object reference. The client of a CORBA object acquires its object reference and uses it as a handle to make method calls, as if the object is located in the client's address space. The ORB is responsible for all the mechanisms required to find the object's implementation, prepare it to receive the request, communicate the request to it, and carry the reply back to the client. Although technically superior, this standard is not popular. Java/RMI relies on a protocol called Java Remote Method Protocol (JRMP). Java relies heavily on Object Serialization, which allows objects to be transmitted as a stream. Since serialization is a mechanism that is specific to Java, both server and client objects have to be written in Java. A server object defines an interface, which accesses the object outside the current Java Virtual Machine (JVM). The interface exposes a set of methods, which indicate the services offered by the server object. For clients to locate server objects for the first time, RMI depends on a naming mechanism called RMI Registry that runs on the server machine. Since Java/RMI is based on Java it can be used on many platforms, however, it cannot be used with other languages, which is a disadvantage. Application FrameworksHaving a distributed object model is one thing, developing and deploying real world applications, however, requires more than that:
Two competing application platforms that achieve these goals have emerged: Sun’s Java 2 Enterprise Edition (J2EE) and the newer Microsoft’s .NET framework. Both frameworks are similar in their intentions and architecture, but completely different in their underlying implementations. Corresponding architectural features include:
Since the .NET framework and J2EE offer similar architectures and capabilities, the decision to adopt either one of them will be based on non-technical issues such as maturity (J2EE is older than .NET), availability of developers, portability and interoperability. It is even likely that, in bigger organizations, both frameworks will coexist and bear collaborating applications using Web services or some other XML-based data exchange mechanism. Application ServersThe explosive growth of the Web, the increasing popularity of PCs and the advances in high-speed network access has brought distributed computing into the main stream. One result has been the rise of a new class of products, called Application Servers. An Application Server is a piece of middleware, created specifically for the deployment of Web based applications. Application Servers handle all the application logic and connectivity that old-style client-server applications contained. A lot has been written about these products, but what are they? Well, it is not obvious to give a clear definition as this definition depends largely on the origin of the companies that market the products. At the low end of the price scale the application development toolmakers, see application servers as an extension of their existing tool sets. The toolmakers offer combined tool-and-application server packages that offer an integrated development environment and runtime server that lets organizations assemble and deploy Web systems quickly and for a modest price. At the opposite end of the price and complexity scales are the transaction processing monitor makers. These high-end systems are the luxury class of application servers, typically used by banks. Many have been around since the dinosaur age of the computer business. The application server wave gives TP monitor makers a new way to market their products to Web developers. In the middle are the database vendors. These companies are now putting Application Servers in a starring role in their product suites. Application Servers and databases go hand-in-hand, and these vendors are emphasizing the back-end connectivity of their products, along with the application development potential. Most large companies already use software from the database and Web server companies, so moving into the application server space should be an easy transition for them. The Open Source application servers such as JBoss and Jonas form another, special group. These systems can be used as an inexpensive alternative for organizations that first want to acquire some hands-on experience with this technology before spending a lot of money on a full-blown commercial solution or as a license-free implementation in the development or test environment. All these groups agree on some common features that an Application Server product has to have. First, application servers need to support the creation of server components conforming to one of the popular application frameworks. Also required is clustering support, load balancing, and fail over features. Connectivity to legacy systems like mainframes and older transaction and database systems is a must, as is support for some sort of business and application logic. Download 1.93 Mb. Share with your friends:
|