Appendix C Buzzwords

ACTIVE SERVER PAGES (ASP)

Active Server Pages are Microsoft’s version of Java Server Pages or vice versa, depending upon your perspective.

The widespread acceptance of Internet standards and business processes that use the Web has increased the number of deployment environments available to a business developer. One such environment is the Web server itself. Normally, a Web server simply sends static HTML documents and other file types to a Web browser. A business process requires much more dynamic content, as information is collected from business systems and presented to the end user.

The original technique used to extend a Web server is a Common Gateway Interface (CGI). A browser can request a CGI program instead of a standard HTML page. The Web server will execute the CGI program or script at the request of the Web browser. The CGI program can in turn reply with HTML data to the Web server; this HTML data is passed along to the Web browser.

However, CGI suffered from poor performance and a lack of frameworks to support it. To solve these and other problems, Microsoft has defined a proprietary extensibility model for their Web server called Active Server Pages (ASPs), or more recently, ASP.Net. ASPs allow the developer to program, or script, Web server processing in much the same way that a Web browser can be scripted. Using ASPs, a developer can integrate data from a database with static HTML code and perform program processing logic. The output of an ASP on the Web server is often standard HTML, which is sent to the Web browser for display.

The ASP environment combines standard components with a choice of scripting languages (VBScript and JavaScript) and an object model that defines the current Web page. Using these resources, the developer can control the content, presentation, and sequence of any part of the Web page as it is created. The result is a rich, dynamic Web page construction environment.

AWT

The basic GUI functionality for Java is contained in the abstract window toolkit (AWT), released with the earliest versions of Java. AWT is a standard interface that Java applications (or applets) can use to create and interact with GUIs. The AWT interfaces talk directly to the underlying graphical operating system interfaces. Since AWT is ported to every Java environment, any Java application that uses AWT can display GUIs in any Java environment.

However, AWT has been generally regarded as the weakest part of the original Java environment. The primary problem is that AWT is too low level for most application developers and does not do a good job of hiding all the differences between graphical hosting systems. At the same time, important capabilities required by graphical applications are not available in AWT. Sun has improved on AWT with the JFC/Swing classes released in the more recent versions of Java.

CLIENT/SERVER

Client/server systems and architecture have changed the way most new computer systems have been built over the last decade and a half. Client/server systems have effectively replaced the traditional mainframe-hosted model as the most popular environment for new business systems in many organizations.

A client/server system is just that, a system with two primary components: a client (typically, a PC) and a server. The client passes messages to the server, and the server performs the requested function and responds with a result. The simplest client/server architecture is a two-tiered relational database model, with a relational database as the server. The application logic is on the client and passes SQL requests to the server. The server responds with data from the database. More complex models involve separate application logic layers, which serve as glue to connect the client to the database server.

The server in a client/server system does not need to be a single physical machine or even a single component. The server often consists of an application server component and a database component. In high-volume situations, there can be more than one application server and more than one database server.

COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA)

I’ve discussed how you can create and use objects as part of your program. In some cases, you may need to create and use objects that exist on another system. Objects can be created and accessed on another system by using an object request broker (ORB). An ORB provides services that allow you to create objects on a remote system and to call that object’s public functions.

The OMG has defined a specification for a standard ORB, the Common Object Request Broker architecture (CORBA). This detailed specification describes which services a standard ORB should provide and how they should be implemented. A number of vendors (such as BEA, HP, Imprise, IBM, and Sun) have implemented products that conform to the CORBA specifications. These products support a wide variety of operating systems and development languages.

CORBA products have been successfully used in a number of large-scale OO projects. They provide good, and efficient, distributed object-management services. However, CORBA products have not had widespread acceptance for a number of reasons:

• Complexity: CORBA products and the CORBA interfaces can be difficult to master. Effective use of CORBA requires a serious commitment to learning a complex technology.

• Language and development environment affinity: One of CORBA’s assets is the fact that it has been designed as a language-neutral and platform-neutral technology. This is also one of its problems. The developer has to step outside the application programming model and address the CORBA model. Only recently have some popular language-specific development environments wrapped CORBA interfaces in a way that feels natural to the application developer.

• Availability and cost: As a rule, development projects that do not have special requirements for deployment will be more successful at project rollout time. If your project requires a CORBA product to be installed at each client system, then you will likely have to manage that task as part of your product installation. You may have to charge for it as well.

• Interoperability: The CORBA spec does not include a working reference model, so minor differences are likely to exist in any actual implementation. In addition, vendors are free to extend their implementations with specific features. As a result, most CORBA products from different vendors do not work well with each other.

COMPONENTS

Components are collections of reusable code, organized so that some other application can use them. Components share many of the same characteristics and design goals as objects (code reuse, public interfaces, and so on), but have a different emphasis. The most important aspect about a component is not how it is built, but rather how it is to be used.

Components can be created in any language and can publish an interface that has little to do with how it is constructed internally. Components are often collections of objects of various types; as such, they can represent a fairly complex service. One example of a large, commonly used component is a relational database system.

Objects can be represented as components, and a component can consist of one or more objects. However, an object will naturally publish its interface based on its class definition and the definitions of the classes it inherits. In addition, unless your development environment supports multiple inheritance (Java does not), it is difficult to publish an OO interface that reflects the results of a coalition of several objects.

Therefore, building a component and using a component architecture is more than just publishing the interfaces of important objects in your Java system. It involves thinking about how client applications might use these objects (or combinations of these objects) and how you should best publish interfaces. In effect, the component designer is building services to be used by other applications.

COMPONENT OBJECT MODEL (COM)

Microsoft’s standard for client-side component access is COM. This is a standard architecture that components can use to publish their interfaces (interactively, at design time, or at runtime). Component consumers can access, modify, and call these components. COM components publish the data items they contain as properties and the functions they support as methods. COM components are language neutral, meaning they can be written in any language and used by any language. However, COM technology is limited in practice to the Windows platforms.

Microsoft development tools can easily wrap your code in COM or COM+ components. All Microsoft environments (even environments that are not, strictly speaking, development environments, such as Excel) can make use of COM components. COM is optimized for performance on a single PC. Applications can use COM without significant performance penalty as long as both component consumer (the client) and the component are on the same PC.

DISTRIBUTED COMPONENT OBJECT MODEL (DCOM)

Microsoft’s standard for distributed object services is its distributed component object model (DCOM). This is both a specification and an implementation. Furthermore, it is technology that is embedded in every relevant software Microsoft product, from compilers to transaction servers to database engines. It is now even part of the Windows operating system.

The good and bad news about DCOM is that it is very Microsoft specific. Most of the challenges listed in the discussion of CORBA are not problems with DCOM, as long as you use only Microsoft, or Microsoft-centric products. If you need to use non-Microsoft products, or non-Microsoft platforms, then the availability of DCOM on that platform will be questionable.

DCOM has the reputation of not performing as well as its competitor, CORBA, although it is hard to find real-world studies that confirm this complaint. On the other hand, DCOM is very easy to use. Since DCOM is based on the ActiveX component standard, most Microsoft compilers can easily create DCOM components, and nearly every Microsoft tool can use DCOM components.

ENTERPRISE JAVABEANS (EJBS)

EJBs bring the benefits of Java-built components to distributed, transaction-oriented systems. An EJB can be instantiated (created) on a remote system, and then respond to message requests from an application executing on a local system. Best of all, EJBs don’t have to manage the complex system plumbing that is normally associated with remote-component management and transaction integrity control. All these system-level issues (component invocation, life-cycle management, security, and transaction semantics) are handled by the EJB infrastructure. A major design objective of the EJB spec is to allow developers to focus on writing code that solves the business problem(s) at hand rather than the technical issues surrounding the management of remote distributed component services.

The EJB specification is primarily an effort to standardize remote component-management techniques available to Java components. It also attempts to simplify and improve existing techniques, such as CORBA and DCOM. EJB is very Java-centric; it fits naturally into the Java language. It is only modestly more difficult to build and use EJB components than it is to build and use regular objects in Java.

The major problems with EJB are these:

• EJB is a Java-only technology: If your project requires transaction and remote object-management services for other languages, then DCOM and CORBA are the only choices.

• EJB is a specification, although there is a working reference model: It is possible that some vendors’ EJB management products may not work well with each other.

• EJB is not built into any operating system: Therefore, Java-built projects that use EJB may have to distribute the EJB components in addition to the Java components.

FILE TRANSFER PROTOCOL (FTP)

The popularity of the Internet is due, in no small part, to the adoption of standard functions by a wide variety of tools. FTP is one of those functions.

FTP is an efficient protocol that can be used to transfer files from one system to another. It includes commands to move binary and text files, one at a time, or in groups. It also includes commands to list the contents of a directory on either the local system or the remote system. Browsers, Web servers, and other Internet tools all support FTP. Often, large file downloads performed over the Internet use FTP as the protocol.

FIREWALL

Web servers are designed to be accessible to the public. An Internet mall, or Internet shopping site, wants to place few restrictions on who can visit the site or when they can visit. A “corporate presence” Web site wants to post information about the company for all to see.

Internet systems, because they are so public, are subject to a variety of attacks from hackers. Hackers can be either just curious or malicious “crackers.” Recent high-profile attacks on government sites have highlighted the potential risks involved in placing important systems in so public a venue.

A firewall system is meant to protect public Web sites from attack. It is placed between the external Internet and the system it is meant to protect. All traffic meant for the protected system is first passed through the firewall, where it is inspected and perhaps rejected. Only approved traffic is allowed to reach the protected Web site.

A firewall prevents most of the obvious attacks by restricting traffic to and from a Web server to approved message types. For example, a firewall might allow only http message requests directed to a specific port (a type of input channel) on a particular Web server. Other requests directed to that Web server (for example, requests to copy files or to change passwords) will be rejected.

HYPERTEXT TRANSFER PROTOCOL (HTTP)

HTTP is another important Internet standard. This is a simple mechanism for a client application (a browser, for example) to request a file from a Web server. Typically, Web pages are accessed using the HTTP protocol.

To use HTTP, a browser needs only to access the file using a public address called a URL (universal resource locator). The HTTP request is automatically directed to the Web server identified in the URL, and the required file is transferred by the Web server to the browser. The browser can then read the information contained in the file, and format a user interface based on the commands in the file.

A Web page ordinarily consists of many files. All the graphics files in a Web page are normally stored on the Web server as separate files. A Web browser actually makes many HTTP requests to get all the files necessary to display a Web page. Only after all the files referenced in the Web page have been downloaded and displayed will the entire Web page be complete.

INTEGRATED DEVELOPMENT ENVIRONMENT (IDE)

Java applications are often developed using an IDE. These tools help the Java developer edit and manage source code, compile applications, and debug problems. Modern IDEs are graphical applications with lots of productivity features, and often include interfaces to source version control systems.

INTERFACE DEFINITION LANGUAGE (IDL)

IDL is both a standard and a technique. IDL files are external descriptions of the interfaces to a component or an object. CORBA includes a standard IDL specification that is used to describe any object that will be managed by an ORB. The IDL Language for Web Services is WSDL.

Development tools often use IDL files to store information about the interface to a component in a readily accessible manner. Some tools allow the developer to use a wizard application to quickly create an IDL based on some existing class. Other tools use IDLs as the repository of information about available components.

INTERNET INTER-ORB PROTOCOL (IIOP)

IIOP is a standard mechanism to pass messages between applications (specifically, between an ORB server and the client that uses the ORB) over the Internet. For example, IIOP can also be used as a protocol by which Web servers accept and respond to ORB message requests from Internet clients. An ORB client will typically be a browser, but any Internet client is acceptable, including another Web server. Most of the popular general-purpose Web servers support IIOP, as do some special-purpose servers built primarily to service IIOP requests. IIOP is specifically mandated as the Internet message protocol for CORBA.

JAVABEANS

A JavaBean is a self-contained Java component. It is a self-describing, reusable software unit intended to be used by another application. A Java bean is a Java class that implements serializable, has a public default constructor, all instance variables are private in scope, and getters and setters for all instance variables. However, modern Java beans do much more than simply provide a means to set and get properties.

A Bean is designed so that a development environment can (visually) publish the Bean’s interface and allow the developer to easily manipulate the interface. A Java Bean supports Java functions that allow a development tool to query the component (introspection). Developers can query the Bean to get additional meta data about its properties (annotation). Beans support events (predefined messages) that can cause the Bean to be stored and subsequently reused (persistence). The Java Bean standard is roughly equivalent to Microsoft’s COM component standard, except that COM is a language-neutral, platform-specific standard, whereas Java-Beans are language specific and platform neutral.

JAVA NATIVE INTERFACE (JNI)

The Java native interface (JNI) is the standard mechanism for Java applications to access functions written in other programming languages, including C and C++. Java applications can also use JNI to access features specific to the host operating system. JNI is supported by all the VMs provided by vendors and on all Java platforms.

JAVASCRIPT

JavaScript is an interpretive scripting language developed by Netscape. It is intended as a generic (that is, cross-platform) scripting language able to extend the standard functionality of Web servers and Web browsers. It doesn’t really have anything to do with Java per se, other than some syntax similarities and its cross-platform promise.

In many situations, a developer needs a programming language in order to implement certain types of application capabilities. Static HTML pages are not always enough to describe an application with rich functional requirements. JavaScript can be used to create programming logic that extends either the Web server or the HTML pages on the client with application logic. When used on the Web server, JavaScript interacts with the data on the Web page and other sources (perhaps data from a database) and generates HTML statements dynamically. Web pages built in this way are interpreted in the standard fashion by a Web browser. On the client, JavaScript interacts with the browser directly and instructs the Web browser to perform functions beyond those available in standard HTML.

JAVA SERVER PAGES (JSP)

Part of the Java 2 Enterprise Edition basket is a technology called Java server pages (JSPs). This is a mechanism to extend a Web server with JavaScript and/or components written in Java (servlets). This product is meant to compete directly with Microsoft’s Active Server Pages (ASP) technology, as a cross-platform development environment for dynamic Web pages that can operate with any Web server.

Using JSP, a developer can build Web pages at runtime based on data from a Java component, static HTML data, or a JavaScript. The result of a JSP is often standard HTML, which is sent to the client by the Web server.

JDBC

The standard Java database access technique is JDBC. JDBC is essentially a variation on ODBC with some Java bindings. It is designed as a Java API to SQL data. JDBC is just a specification; it is up to the various database vendors or third parties to create JDBC drivers for a particular database. In some cases, a JDBC-ODBC bridge can be used, but likely not for production purposes.

JDBC provides a fairly complete set of SQL-friendly data access mechanisms, such as scrollable result sets, absolute and relative positioning (in the result set), access to stored procedures, and data type conversions. Most SQL-92 (Entry Level 2) statements are supported in JDBC.

MICROSOFT FOUNDATION CLASSES (MFC)

Low-level programming in Microsoft Windows can be a very complex and tedious task. Windows comes with hundreds of APIs, most of which are designed to display and manage the GUI. Each new release of Windows comes with a new batch of APIs that may or may not be useful to your project but will certainly clutter up the API reference manual.

Microsoft has attempted to simplify this complexity with its Microsoft Foundation Class (MFC) libraries. The set of libraries is designed to let the C++ programmer easily access the most commonly used UI components, without sacrificing power or flexibility. Furthermore, the MFC programmer can create specializations of the base MFC classes for his or her own purposes. Most sophisticated Windows applications today use MFC classes and the MFC programming environment.

OPEN DATABASE CONNECTIVITY (ODBC)

ODBC is a standard data access technique developed by the SQL Access Group in the early 1990s. This is a specification for a standard call level interface that supports access to data sources. Various vendors, including all the major database vendors, have developed ODBC drivers that can be used to access information stored in their databases. ODBC drivers are now shipped as a standard component of Windows systems.

Although used primarily with a SQL database, ODBC is sometimes used to access information from other sources, including text files, spreadsheets, and ISAM files. ODBC drivers also are available on other platforms besides Windows, such as UNIX and Macintosh.

REMOTE METHOD INVOCATION (RMI)

Sun has defined a standard technique that Java applications can use to create objects on remote systems, and then call their methods. This standard, called RMI, is similar in principle to traditional RPC function calls (see the “Remote Procedure Call” section), except that it is tailored for Java. Most Java runtimes (but not all) contain the libraries necessary to support RMI. RMI is an essential building block for EJBs.

REMOTE PROCEDURE CALL (RPC)

Remote procedure call (RPC) is a generic name for a protocol that allows an application on one system to call a function on another system. The best way to understand RPC is to start with a normal procedure call. Suppose that program A calls program B with parameters and then waits for the reply. When program B is complete, it returns to program A, perhaps with return parameters. In an RPC environment, program B can be on another system.

In most RPC implementations, the caller must perform a small amount of specialized logic to initiate the called program on the remote system before calling the remote program. After initialization, an RPC implementation makes the remote program appear as if it were local, except for the performance penalty incurred by remote function calls as compared to a local call.

SECURE SOCKETS LAYER (SSL)

SSL is a transmission protocol designed by Netscape that employs encryption techniques to provide secure transmissions over the Internet. Other service-based utilities, such as HTTP and FTP, can employ SSL to secure the messages they send over the Internet.

SSL sits between these service utilities and the Internet’s basic message-passing protocol (TCP/IP). For example, an HTTP server that uses SSL (such as https://www.domain...) talks to the SSL layer, which encrypts the message and then sends it out over TCP/IP. On the other end of the message pipe, the browser reads the message from the SSL, which gets the encrypted message from TCP/IP, decrypts it, and returns it to the browser. SSL hides the message content sent between partner applications from public scrutiny.

SWING

The basic GUI functionality for Java is contained in the abstract window toolkit (AWT). However, the AWT has been generally regarded as the weakest part of the original Java environment. Sun has improved on AWT with the newer Java Foundation Classes (JFCs), originally released as a patch to SDK 1.1. These APIs are grouped in a package named after the internal development project at Sun (Swing). The Swing package is meant to replace the AWT.

Applications that use Swing have access to more control over the user interface. For example, an application can now manage borders around Swing components, and Swing components do not need to be rectangular. Swing applications can interact better with native applications.

On the downside, the Swing components are fairly large. A Swing application must download the Swing components to the client if they are not already loaded.

TCP/IP

The standard transport protocol for the Internet is transmission control protocol/Internet protocol or TCP/IP. This low-level protocol defines the way messages must be packaged, delivered, and accessed by systems on a network. Other service-based utilities, such as HTTP and FTP, employ TCP/IP as the wire-level protocol to perform their functions.

TCP/IP’s most popular feature is the ability to create a virtual pipe between a client and a server application. The client and server can use this pipe to send messages to each other, simply by reading and writing to the pipe, as if it were a file. These messages are tagged as belonging to a specific client and server application. Other client applications and other server applications will not see these messages, even if they are on the same machine. Web browsers and Web servers use this capability when they send and process HTTP requests, for example.

By virtue of these and other features, TCP/IP facilitates the transfer of information between applications over a public network, such as the Internet.

UNIFIED MODELING LANGUAGE (UML)

The unified modeling language is a definition of a software modeling language. Software modeling techniques employ rigorous analysis and documentation methodologies to capture a representation of how a system is built and how the system performs its processes. UML combines features from existing software-modeling practices. At the same time, UML is intended to be simpler, or more approachable, than some of the previous modeling techniques.

The UML is a rich language that can represent all sorts of system processes, from simple data entry functions to complex real-time distributed systems.

UNIFORM RESOURCE LOCATOR (URL)

URL is a standard convention that identifies a unique location for a file, or other resource, in a manner that is unambiguous. Any application, such as a browser, can use a URL name to locate a file. You are likely familiar with URLs already. The name of your favorite Web site is identified with a URL (www.cnn.com, for example).

The first part of a URL is the protocol used (e.g., HTTP or FTP). The second part of a URL identifies the domain name that contains the resource. A domain name is a publicly registered ID of a server on the Internet. Domain names are assigned by government-affiliated organizations to an organization or individual. Domain name servers on the Internet resolve individual domain names to a specific identifier called an IP address. The format of an IP address is nnn.nnn.nnn.nnn, in which each n is replaced with a number.

A domain is either a unique physical server or a logical location on a server. It can even be a collection of servers (a server farm), grouped to appear as one.

The remainder of the URL name (that is, the characters after the domain name) point to a file, a directory, or some other resource located on the server.

VBSCRIPT

Microsoft has developed its own Web scripting language called VBScript. VBScript is similar in many ways to JavaScript. Like JavaScript, VBScript provides an environment that allows the developer to perform programming logic dynamically (at runtime). VBScript can be executed on either a Web client or a Web server. As the name suggests, VBScript is similar in syntax to Visual Basic (VB). VBScript and JavaScript can usually be combined on the same Web page.

WEB SERVICES

A Web service is simply an application that can be addressed as a URL and pro-grammatically returns information to clients who want to use it. Clients don’t need to know how a service is implemented because it is component based.

Like components, Web services represent black-box functionality that can be reused without worrying about how the service is implemented. Web services provide contracts that describe the services provided. Developers can assemble applications using a combination of remote services, local services, and custom code.