WebSphere Enterprise Services in Java

Painting Denso QR Bar Code in Java WebSphere Enterprise Services

It is difficult to imagine a situation in which you would actually make use of all these products at the same time, because in some cases their capabilities overlap But one cannot ignore the fact that Enterprise Extensions provides products and capabilities that will handle virtually any requirement for high levels of distribution, transaction support, messaging, and practically anything else One of the major things IBM did in version 40 was to take the three editions of version 35 (Standard, Advanced, and Enterprise) and merge them into a single code line In version 40, the features that previously could only be run on Enterprise Edition can now be run on WebSphere Advanced Edition by installing Enterprise Extensions Component Broker Component Broker is an object engine that supports the Common Object Request Broker Architecture (CORBA) model, as well as EJB Since the EJB specification has been expanded to place Remote Method Invocation (RMI) over the Internet Inter-ORB Protocol (IIOP), J2EE servers have a lot of CORBA support by definition We believe that Component Broker appeals only to organizations that have an existing investment in other programming languages, such as C++, and to those whose environment includes a mix of programming languages so that they are unable to commit to a Java environment The reason is that most of the extra functionality provided by the Component Broker relates to supporting code and functionality in languages other than Java, and to object models other than EJB IBM provides the C++ CORBA software development kit to facilitate a standard way of integrating C and C++ code into the J2EE environment, and of building and deploying C++ CORBA clients Apart from being an Object Request Broker (ORB) and supporting EJB, Component Broker also provides support for a large number of services that are useful when building business applications These services include concurrency control, lifecycle, event, notification, object identity and naming, security, transaction, session, query (via the Object-Oriented Structured Query Language (OOSQL) standard), cache, and workload management services TXSeries TXSeries is actually two different products TXSeries CICS (Customer Information Control System) and TXSeries Encina Both products are transaction monitors that are used by applications with extremely high transaction requirements, and both are completely unrelated to the world of Java and the Internet With TXSeries, IBM has managed to provide developers with connectors that conveniently "glue" these products to WebSphere Application Server MQSeries MQSeries is a distributed messaging solution from IBM The appeal of this product and the appeal of integrating it into WebSphere is the fact that it is used by many corporate developers MQSeries is similar to the TXSeries products, and IBM has managed to provide excellent connectors (or adapters) for using it from within Java code MQSeries also includes support for using MQSeries within the context of the Java Messaging Service (JMS) API

Enterprise Services The last major component of Enterprise Extensions is WebSphere Enterprise Services, which essentially is a collection of capabilities offered by IBM that didn't make it into the J2EE standard The services include ActiveX Bridge Allows developers to extend J2EE EJB connectivity to existing software components based on Microsoft's Component Object Model (COM) technologies Internationalization Service Provides mechanisms for implementing J2EE applications in a manner that adapts presentation and business logic based on different client locales and time zones Note that Java has built-in support for internationalization, but that the requirements for this functionality become more complex in the setting of J2EE applications, where a single transaction can span several locales Extended Messaging Support Allows the J2EE server to accept inbound asynchronous messages via a JMS listener Business Rule Beans Enables the encapsulation of business rules outside of application code, in an external rules set Shared Work Areas Provides an abstraction of shared memory for J2EE applications, allowing developers to share information between objects without invoking explicit methods or passing messages Business Process Beans (Technology Preview) Provides advanced business process support via different transaction processing paradigms This framework allows chained J2EE transactions, automatic initiation of transactions using time-based or messaged-based triggers, and concurrent invocations of J2EE components, such as EJB and connectors Platform Support The whole line of WebSphere servers is currently offered on most major operating systems It is available for Microsoft's Windows NT and Windows 2000, as well as for most flavors of UNIX, including Sun Solaris, IBM AIX, Red Hat Linux, and HP-UX Because it is an IBM product, it is also available on IBM AS/400 You can connect to any relational database having a Java Database Connectivity (JDBC) driver by including that driver in the classpath of the Java application server Since some elements make use of built-in WebSphere features (such as database connection pooling, automated persistence, and so on), it is not enough to plug in the driver in some cases The primary database platform supported (besides IBM's own DB2) is Oracle 8 In this book, our examples will use DB2 and Oracle but they can be easily implemented on any other database with JDBC support The major databases supported are DB2 Oracle Informix Sybase SQL Server For more details on supported products, see the following Web site: http://www-4ibmcom/ software/webservers/ appserv/doc/v40/ prereqs/ae_v401htm The WebSphere Family of Products This section reviews the WebSphere family of products beyond the Application Server 6

WebSphere Studio Application Developer WebSphere Studio Application Developer (WSAD) is a new product within the WebSphere line It is a merge of VisualAge for Java and WebSphere Studio It therefore targets Java developers, Web site and script builders, and more VisualAge for Java is IBM's Java Integrated Development Environment (IDE) Apart from being a full-blown IDE for Java and being an advanced tool for developing, testing, and debugging Java applications, it includes inherent support for WebSphere Namely, it allows you to develop servlets, JSPs, and EJBs, and run them from within VisualAge for Java The execution environment provided by VisualAge for Java is a downsized version of the actual WebSphere server Realizing the scarcity of development resources in large organizations, IBM developed two variants of VisualAge for Java that allow developers with little or no Java skills to generate code and to develop applications: VisualAge Application Rules Allows you to quickly build and deploy rule-based applications Using other IBM tools and middleware, you can build large applications relatively easily VisualAge Generator Allows rapid development and deployment of Web-based applications, which mask the complexities of transactions, communications, and databases WebSphere Studio provides a powerful set of tools for building dynamic Web pages and applications It provides a visual authoring environment for designing pure HTML pages and pages with JavaScript, Dynamic HTML (DHTML) and JSPs As with other WebSphere-related products, WebSphere Studio works in harmony with the WebSphere server and VisualAge for Java Another product that provides a visual editing environment for Web pages with dynamic content is WebSphere Homepage Builder, formerly known as TopPage WebSphere Business Components WebSphere Business Components is a library of components aimed at saving time for application developers The various components have well-defined interfaces and provide rich functionality By and large, the components provided in this package are EJBs, which increases their usability and portability, and shortens the learning curve for using them The WebSphere Business Components product is based on a previous product named SanFrancisco Project SanFrancisco started out when several large IBM customers went to IBM and asked for assistance in upgrading a set of enterprise-level, mission-critical applications to new technologies These companies had large application suites in various business domains, and were interested in replacing their old technology bases (often COBOL running on a mainframe) with object-oriented, network-centric architectures The implications of widespread technology migration and application rewrites were so great that these companies requested guidance and assistance from their large vendor, IBM As the relationships with IBM around the technology migration were formulated, a few areas in which IBM could assist were defined Technology adoption, retraining, and knowledge transfer were areas in which IBM clearly could help Analysis and design were also targeted: skilled developers and analysts from IBM could be involved with internal development projects to bootstrap processes and make sure that designs were done correctly As these relationships formed, however, it became clear that more was necessary As is always the case with new technologies, they hold much promise but 7

initially lack many infrastructure components that come with years of use and market maturity Multitier software architectures and network-centric application infrastructure is no exception The companies working with IBM, along with IBM itself, identified fairly early on that they would all benefit greatly if some infrastructure components were put in place that could then be reused throughout the business systems being created And so project SanFrancisco was born Project SanFrancisco started with wide-scale analysis of the business systems for which it would be used It was then constructed as a set of business process components that could be reused within multiple business systems and domains Quite early on, the fundamental structure of the project was set to make use of the notion of object-oriented frameworks as opposed to class libraries, for example As such, SanFrancisco provided an infrastructure a consistent design and programming model, along with default business logic that could be changed and extended Reusable object-oriented software components are certainly not new to the software industry, and even in terms of frameworks, the market has already seen some excellent implementations Nevertheless, SanFrancisco implemented the largest, most complete set of frameworks of all In addition, it was one of the first examples of frameworks that included high-level business functionality; most frameworks used today solve only lowlevel system issues and user interface problems So what is the state of the project SanFrancisco was a collaborative effort led by IBM, involving hundreds of international independent software vendors (ISVs) that were willing to base their system architectures on the SanFrancisco frameworks and to help stabilize and form the ultimate structure of the product While SanFrancisco included many frameworks, services, and utilities, the core of the environment was made up of three software layers with increasing proximity to business applications: the Foundation layer, the Common Business Objects layer, and the Core Business Processes layer Each of these layers relied on the previous layer (see Figure 1 -1)

Figure 1-1: SanFrancisco framework The Foundation layer implemented the infrastructure and services available for all objects participating in the SanFrancisco environment It supported the notion of object persistence, transaction processing, distribution and location transparency, naming, security, ownership, and so on It was the largest layer, and the one that provided context-free, infrastructure-related support useful for all applications The Common Business Objects layer implemented a set of elementary business objects common to a very large set of business domains These objects included addresses, money-related objects, customer and location, and more The final layer, Core Business Processes, provided complete sets of business objects and processes that formed sets of mini-applications and included working functionality that was useful in the relevant domains This layer actually was not one layer, but rather a set of vertical layers, each providing support in a certain domain Naturally, the first verticals to be selected were those most relevant to IBM customers; however, as time went on, additional verticals were added By understanding and using both the Core Business Processes and the Common Business Objects, one could customize the SanFrancisco frameworks either through derivation or composition (or a combination of both), making the end result extremely attractive The simplest reuse scenario involved using business objects and processes out of the box while setting properties that were built-in parameters of the business objects The next level of complexity allowed you to alter the way in which objects were created and to define which class would be used for instantiating a certain business concept By supplying your own extension to the business class, you could customize behavior while remaining within the framework Alternatively, you could fully extend a domain's class through substitution, or through derivation and modification, of functionality 9

As shown in Figure 1-1, the Foundation layer and the Common Business Objects layer form the SanFrancisco Base The base layers provided the services and the underlying object support required for building multitier, distributed, object-oriented applications, along with a fundamental set of objects that conformed to the SanFrancisco patterns This not only allowed the application builder to be semi-oblivious to the difficulties involved with complex application architectures, it also helped to jump-start the development process The Core Business Processes complemented the base with rich functionality in various domains, all while building on the base As Figure 1-1 shows, an application builder was not limited in how the frameworks could be used Applications could be built within one or more of the Core Business Processes, in which case SanFrancisco could provide the most bang for the buck If the domain was not covered by one of the process frameworks, or if the functionality provided was too different from the one required, the application could make use of the Common Business Objects layer as a set of reusable business objects that functioned within the SanFrancisco environment This use saved a lot of development time and even more testing time, but still required more work than did use of the Core Business Process layer Finally, new business objects were sometimes created directly over the Foundation In this case, the new business objects made use of the underlying services only, which solved the most complex issues in the system architecture Obviously, any combination of the described alternatives was possible; an application may have used parts of the Core Business Processes or some of the Common Business Objects directly, combined with a set of objects using Foundation layer services Once all pieces of the application used these services, the objects worked in tandem We mentioned that as long as objects were built over the Foundation layer, they formed a coherent application structure Building objects that are external to the foundation to work at the application level was much more difficult and was not recommended As long as objects used the Foundation layer services and conformed to the SanFrancisco patterns, they could participate in the SanFrancisco world and thus make use of the benefits Objects not built in this way needed to solve many difficult problems, such as persistence, transactions, and so on Even worse, if you decided to depart from the SanFrancisco model, you had to synchronize and maintain the two models For example, if you had a single business transaction that included objects using the base and objects that required self-management for transactions, you somehow had to synchronize all of this into one transaction something that really should not be attempted without serious "adult" supervision The SanFrancisco project was not successful In fact, it was highly unsuccessful given the amount of investment funding that IBM poured into it (as well as into Taligent, which formed some of the roots of SanFrancisco) When WebSphere emerged as the dominant Java and e-business platform that it is, IBM quickly repositioned and rebuilt SanFrancisco on top of EJB as the base framework and on WebSphere as the deployment environment WebSphere Business Components is still expanding, and it appears to be a promising line of products; it certainly implements a lot of business functionality! WebSphere Transcoding Publisher One of the challenges of developing applications for today's Internet is the multitude of devices that can access the Web In addition to the traditional PC-based and UNIX based browsers, there are growing numbers of personal digital assistants (PDAs) and cellular phones that provide Web access For such devices, it is either required or helpful to produce content in a manner that matches the device capabilities In other 10

words, content must be reformatted to fit the screen, and possibly be presented in a different markup language altogether For example, cellular phones might require content in Wireless Markup Language (WML), part of the WAP standard, or Compact HTML (CHTML) Enter WebSphere Transcoding Publisher This product provides you with the capability to reformat and adapt your data on the server side, according to your needs WebSphere Voice Server A recent venue of expansion for Internet applications is the realm of voice services, via call centers and voice portals IBM has moved into this domain with the WebSphere Voice Server This server builds on the WebSphere server and VoiceXML (a special variant of XML for voice-based documents), and provides the tools for building Webbased voice portals and call centers WebSphere Portal Server A few years back, portals were "the next big thing" in the Internet world The glamour has now faded away, but on the other hand, any company can build its own custom portal Web site with products such as WebSphere Portal Server It allows users to sign in and receive personalized content and, of course, it may be built to contain any specific content required to serve the needs of customers, business partners, and employees WebSphere Everyplace Suite The WebSphere Everyplace Suite is IBM's player in the mobile computing and mobile Internet arena While some of its capabilities overlap those of the WebSphere Transcoding Publisher, this product aims to provide a complete out-of-the-box solution for building sites for mobile users accessing content from PDAs or cellular phones WebSphere Everyplace Suite includes a client-side component called WebSphere Everyplace Embedded Edition WebSphere Personalization WebSphere Personalization gives you the capability to provide users with personalized content that is customized for their individual needs and preferences Obviously, the same effect can be achieved with a relatively small programming effort using WebSphere Application Server itself WebSphere Edge Server Previously called WebSphere Performance Pack, WebSphere Edge Server provides a multitude of performance capabilities These include load balancing, content-based routing (which affects quality of service), content filtering, and content caching It is important to note that this product works with various Web servers, not necessarily just IBM's WebSphere Site Analyzer WebSphere Site Analyzer provides Web site visitor activity and usage capabilities The power of this product stems from the fact that it provides all the data required for analyzing Web site visitor behavior, and at the same time is tightly integrated with other IBM products, such as the WebSphere Application Server itself and WebSphere Commerce Suite 11

Tivoli Policy Director Tivoli Policy Director is a part of the Tivoli family of products It is aimed at managing the security policy for e-business and Web-based applications WebSphere Commerce Suite WebSphere Commerce Suite provides tools for building e-commerce sites quickly and relatively easily WebSphere Commerce Suite includes a subproduct called WebSphere Payment Manager which, as the name implies, is used to manage payments WebSphere Business-to-Business Integrator B2B is yet another buzzword that has lost its glamour with the bust of the dot-com bubble WebSphere Business-to-Business Integrator allows you to bridge the gap between your own company's enterprise computing systems and those of customers, suppliers, and business partners The basic technology for doing all of this is XML, but this product combines some of IBM's integration and transaction products WebSphere Partner Agreement Manager WebSphere Partner Agreement Manager allows an organization to automate interactions with partners (suppliers, for example), customers, and e-markets Suc h automation can help improve supply chain efficiency and effectiveness

Summary Because this book is a reference on the topic of developing Web applications using WebSphere tools and deploying them on WebSphere Application Server, it does not go into detail on most of the products in the WebSphere family that were mentioned in this chapter In fact, many of these products deserve "complete references" of their own As this book focuses on WebSphere Application Server only, it provides much detail on EJB, servlets, JSP, all aspects of J2EE, deployment topologies, and much more

2: Installing and Starting WebSphere Overview This chapter delves into WebSphere and runs through a typical installation You will walk through a complete installation procedure for Windows (NT or 2000) and for Linux IBM does not currently support Windows XP, and the plan is to support it formally in the version 50 product line only Still, we have been running on XP for quite a long time; as long as you don't try it in a production environment, you will probably be OK The installation procedure for UNIX platforms is quite similar to that for Linux Some troubleshooting tips are covered later in the chapter, although in most cases, installation should go smoothly By the end of this chapter, you should be ready to install WebSphere on your machine with no problems To initiate the installation process, you need to open the installation program, which is available on a CD or as a download from wwwibmcom/websphere An evaluation version of WebSphere Application Server Advanced Single Server Edition is provided in the CD that accompanies this book Windows Installation Once you start the installation program, the first window that pops up is the warning window Apart from indicating that WebSphere is copyrighted, this warning window also recommends closing any open applications This is extremely important if you are running a Web server or a previous version of WebSphere You should shut these down prior to continuing with the installation WebSphere 40 does not require a Web server Version 40 comes with a built-in, fully functional Web server, which runs on port 9080 It is not recommended for production use, but it does allow a user to test a WebSphere Application Server (WAS) installation without installing a Web server

For a production environment, we suggest you install a Web server (or an HTTP server) to work with, such as Microsoft IIS, iPlanet, Apache, or Lotus Domino The WebSphere installation includes the default application server, which is IBM HTTP Server If you want to use WebSphere with a different Web server, you must install it prior to running the WebSphere installation Web servers are discussed at length in 6

If you already have a version of WebSphere installed, the installation program will automatically detect it and offer to either upgrade it or install a fresh new copy (see Figure 2-1) Of course, if you've never installed WebSphere, this offer will not appear

Figure 2-1: Detecting an existing version of WebSphere After you've made your selection, or if you don't have WebSphere installed, the Installation Options window appears, offering two different installation methods The first option, Typical Installation, installs IB M HTTP Server and the IBM Java Developer's Kit (JDK) 130, along with the WebSphere Application Server The JDK used for WebSphere is the IBM JDK 130 The second option, Custom Installation, allows you to select which components to install Specifically, it lets you select a different JDK and install other Web server plug -ins (see Figure 2-2) Note that if you use a JDK, you must first ensure that it is works correctly with WebSphere Obviously, JDK 130 from IBM will work perfectly

Figure 2-2: Custom installation If you don't intend to use IBM HTTP Server, deselect this option in the dialog If you select Web Server Plugins, WebSphere prompts you to select which plug-ins you want, as shown in Figure 2-3