In This Chapter
Change today happens suddenly, unexpectedly, unpredictably. Change is sudden, nonlinear, and constant. Its amplitude and direction can’t be forecast. Markets emerge, flourish, inspire imitators, breed competitors, and disappear seemingly overnight... Organizations that want to prosper over the long term need to practice the art of continuous change.—Former Secretary of Labor Robert Reich.
Organizational research clearly states that if your organization desires to be future proofed to exist and achieve success, your organization must expect change, accept change, and embrace change in such a manner that opportunities presented by change are seized to develop competitive advantages in your specific business domain. The degree to which your organization can accommodate and leverage change is known as its organizational agility.
Taking the concept of organizational agility and applying it from a technical perspective implies that the application infrastructure you choose as a foundation software platform for your business solutions must be as fluid as the changing environment in which it exists, providing a catalyst for ongoing innovation and continuous return on investment based on your own organizational ROI criteria. Your application infrastructure, which in essence influences the development, deployment, management, and integration capabilities of your software solutions, is what will allow your technical architectures to naturally mold and adapt to your changing business requirements, as well as bridge interfaces between existing systems without costly and time-consuming infrastructure overhauls.
This chapter provides an introduction to BEA WebLogic Platform 7, a comprehensive application infrastructure offering, with built-in agility derived from proven and battle-tested BEA infrastructure technologies—WebLogic Server, WebLogic Portal, WebLogic Integration, and WebLogic Workshop. This technology stack offers a single, unified, and extensible infrastructure platform for application development and provides a natural migration path for WebLogic Server, WebLogic Portal, and WebLogic Integration customers seeking to deploy solutions that enhance or extend their existing technical environments via a single, integrated architecture.
In today’s very competitive economic climate, it is inconceivable to think that large, global organizations rely on application infrastructures that are composed of multiple layers of incompatible technologies to power their mission-critical enterprise applications. However, this scenario is very common. For example, if your organization
Develops, deploys, manages, integrates, and secures its enterprise applications using a disparate range of technologies
or
Faces tremendous complexity, extensive delays, and enormous expense to develop, extend, or integrate legacy, packaged, and custom applications
it unfortunately suffers from an application infrastructure problem, which will undoubtedly prevent your organization from achieving technical agility when required. There are numerous reasons that an organization can have application infrastructure problems, and probably the most common is that the technology areas prevalent in most enterprise solutions to power business solutions, as illustrated in Figure 9.1, are addressed and implemented as disparate and autonomous islands of technologies (Business/Technology silos).
Figure 9.1. A common scenario of using technology infrastructure in an organization that is not technically agile.
To address this application infrastructure dilemma and the increasing need BEA customers have for a unified, simplified, and extensible application infrastructure platform, as illustrated in Figure 9.2, BEA introduced WebLogic Platform 7 as the first application infrastructure offering represented through a single product—one documentation, installation, configuration, deployment, management, and security framework.
As illustrated in Figure 9.3, WebLogic Platform 7 is uniquely built around WebLogic Server, which integrates seamlessly with the functions of the following components:
WebLogic Integration, which offers comprehensive integration services.
WebLogic Workshop, an application development framework for Java, Web services, and XML application development, which is designed so that both Java development experts and corporate application developers can easily create, test, and deploy Web services, regardless of their programming experience.
The benefits of adopting WebLogic Platform as your application infrastructure include the following:
WebLogic Platform provides a single, unified architecture that reduces the number of products to support, maintain, and integrate, as follows:
The unified integration, portal, and application server components included in WebLogic Platform provide a single set of core services, components, and enterprise-class capabilities for application development and integration.
WebLogic Platform uses a single installation program to install all its components. This unified installation approach ensures that all software components and examples are placed in the appropriate directories so that the platform works immediately upon installation and without additional configuration steps.
The presentation and consumption of Web services is supported through the platform’s portal framework (WebLogic Portal).
The orchestration of Web services around business processes is supported by the platform’s integration framework (WebLogic Integration).
The reliable, scalable, and highly available Web service runtime environment is supported by WebLogic Server.
The integrated development framework (WebLogic Workshop) provides developers with a means to easily build, deploy, and test Web services.
WebLogic Platform uses one security framework for the WebLogic Server, Portal, and Integration products, which unifies security for enterprise applications.
WebLogic Platform is supported as one single product offering, which implies that all its technology products are tested for complete interoperability before release.
WebLogic Platform provides one application management infrastructure for administering and monitoring portal, integration, and application server components.
Because WebLogic Platform is built on WebLogic Server, all WebLogic Platform applications take full advantage of the world-class reliability, availability, and scalability services of WebLogic Server.
WebLogic Platform uses a unified Java Messaging Service (JMS) across its technology products.
WebLogic Platform increases productivity through simplified application development, deployment, and management, as follows:
WebLogic Platform provides integrated development tools for portal, integration, and Web services development efforts. For example:
EBusiness Control Center (EBCC) simplifies the creation, customization, and administration of portals.
Integration Studio provides a visual environment for integration specialists to develop workflows between business processes.
WebLogic Workshop provides developers with an intuitive graphical environment for creating Web service applications and a runtime framework for deploying these applications to WebLogic Server. The Workshop framework also provides further infrastructure to make sophisticated Web services architectures easy to implement. Examples are the ability to develop asynchronous, loosely coupled, and course-grained architectures with a few clicks of the mouse—critical requirements for developing enterprise-class Web services.
Because WebLogic Platform is built on WebLogic Server, it is fully J2EE compliant; hence, you can leverage the best J2EE enterprise development tools (for example, TogetherSoft’s Together Control Center and Borland’s JBuilder) to custom-build your J2EE applications.
The new Domain Configuration Wizard simplifies the generation of new WebLogic domains, reducing any initial setup errors for a WebLogic Platform domain.
The WebLogic Platform QuickStart and Product Tour provide developers with an end-to-end working tutorial and features guide on how to develop applications on WebLogic Platform.
The WebLogic Builder tool provides a graphical interface for assembling and deploying a J2EE application to WebLogic Platform, including full editing capabilities of the respective deployment descriptors.
The Smart Update agent unites all platform component updates into a single update package, reducing the effort and risk of upgrading WebLogic Platform 7 to future versions.
WebLogic Platform 7 provides open extensibility to your application infrastructure functionality, thus future-proofing your technology investments, as follows:
WebLogic Platform is supported by the world’s leading operating systems and databases and supports cross-platform deployments.
WebLogic Platform’s resources are fully configurable to the architectural standards required for organizations.
WebLogic Integration’s framework provides standards-based application integration as well as support for B2B and data integration.
The WebLogic jCOM product provides bidirectional functional interoperability between WebLogic Platform and Microsoft’s Distributed Common Object Model (DCOM) infrastructure.
WebLogic Platform provides leading support of Web services standards (SOAP, WSDL, UDDI), integration standards (J2CA, JMS, JDBC), and emerging standards around portal functionality (JSRs 94, 127, 168, 170, and WSRP).
WebLogic Platform includes the ability to communicate with enterprisewide management systems using Simple Network Management Protocol (SNMP), which enables you to integrate the management of WebLogic Platform solutions into an SNMP-compliant management system that gives you a single view of the various software and hardware resources of a complex, distributed system.
WebLogic Platform fully supports the Java Authentication and Authorization Service (JAAS), thus providing an open infrastructure for plugging in third-party security solutions.
The following sections describe the BEA technology products that constitute WebLogic Platform—WebLogic Server, Workshop, WebLogic Portal, and WebLogic Integration.
BEA WebLogic Server 7 is the most widely adopted J2EE application server that is fully compliant with the industry-standard Java 2 Enterprise Edition version 1.3 platform, the programming model of choice for server-side development of enterprise-class applications.
WebLogic Server also implements the J2EE Connector Architecture (J2CA), which enables developers to connect Enterprise Information Systems (EISs) to the J2EE platform and to apply J2EE component models, transactions, and security infrastructures toward the integration of these systems. Table 9.1 shows the full list of J2EE application programming interfaces (APIs) and other leading Internet technology standards supported by WebLogic Server.
Table 9.1. J2EE 1.3 APIs and Other Leading Internet Technology Standards Supported by WebLogic Server
Full compliance with the J2EE platform and the leading Internet standards ensures that applications built and deployed on WebLogic Server have the following capabilities:
Are portable across a wide variety of hardware and operating systems and, therefore, are easier to integrate with applications running in heterogeneous environments, such as Unix, mainframe, and Windows. Heterogeneous environments are typical in most organizations.
Can leverage a variety of best-of-breed third-party tools and components written to the J2EE APIs.
Can integrate with prebuilt applications and components that conform to J2EE and the other technology standards described in Table 9.1.
Unlike the J2EE standard, however, an application server is a commercial software product that different vendors develop and sell. All application server vendors must make sure their products are certified and fully compliant with the J2EE platform (see Figure 9.4) by ensuring the following:
Developers are responsible for implementing the J2EE components (servlets, JSPs, and EJBs).
Containers deliver the runtime environment, which encompasses access to the J2SE and J2EE APIs as well as remote communications services (such as RMI).
J2EE is to the application server what SQL is to the relational database management system (RDBMS). Does implementing SQL imply that an RDBMS product provides all the services and features required by today’s enterprises? It does not. Oracle, Sybase, Microsoft, and other leading database vendors use SQL to provide a common access language to their products only. Everything else, such as the reliability, availability, and scalability of their products, is designed and implemented based on their efforts to be competitively aligned with the features a high percentage of organizations (customers) are seeking from relational database management systems. By forecasting and successfully satisfying these customer feature requirements, these software vendors gain leadership and a competitive edge in their product space.
Likewise, the J2EE specification standardizes only the Java APIs (contracts) between components and the application server containers, and is nothing more than a definition of application infrastructure services. It is a common misconception to think that the J2EE specification covers all aspects of application infrastructure. It does not! For this reason, it is the responsibility of the application server vendors to implement the J2EE specification in an application infrastructure that also supports nonfunctional and Quality of Service (QoS) attributes, such as the following:
Reliability—. Ensures that applications never “break,” even under the most demanding circumstances.
Availability—. Meets the accessibility requirements set forth by the service-level agreement of a business solution.
Scalability—. Allows organizations to cost-effectively embrace any level of application usage, while maintaining a reasonable response time.
Security—. Provides application- or component-level security mechanisms that can easily be leveraged across integrated business solutions to provide a unified security framework.
Adaptability—. Provides the extensibility of a business solution.
Compatibility—. Allows multiple hardware platforms and other infrastructure solutions to interoperate.
Manageability—. Provides administration, change management control, and root cause diagnostics for business solutions.
Reuseability—. Allows services to be leveraged across multiple business solutions.
The degree to which an application server satisfies these non-J2EE and QoS attributes is what distinguishes it as a market leader.
BEA WebLogic Server is by far the leading J2EE application server and has been for many years. This is true not because it has always maintained compliance with the current J2EE standards, but because it provides a complete development and deployment environment for J2EE applications through other infrastructure services that J2EE enterprise applications demand and are not covered by the J2EE specification.
WebLogic Server goes beyond J2EE by addressing and delivering the following application infrastructure requirements:
Broad client support for browsers, wireless devices, and programmatic clients.
High performance, which is facilitated by in-memory replication, clustering, caching, asynchronous JMS messaging, and multithreading capabilities.
Scalability offered by load balancing, caching, pooling, and a distributed naming service (the Java Naming and Directory Interface, or JNDI).
High availability with an unparalleled clustering capability, which encompasses failover and in-memory replication.
A new self-health monitoring feature to monitor the health of WebLogic servers in a domain. Along with the WebLogic Node Manager process, the self-health service can be used to manage the availability of those servers deemed to be in a failed state.
A new security framework encompassing all WebLogic products and including support for user- and group-level Access Control Lists (ACLs), realms, Secure Sockets Layer (SSL), digital certificates, JAAS, and encryption. This flexible security framework enables you to easily plug in solutions from best-of-breed security vendors, such as Pentasafe, RSA, and Netegrity. Also, a built-in LDAP-based security data store is included to store and process all the necessary security credentials and other information the system administrator maintains.
A new Transaction Recovery Service (TRS), which attempts to recover failed transactions with a commit or rollback upon server startup.
Interoperability between different versions of WebLogic Server.
Broad deployment options, which permit tight integration with the leading databases, operating systems, Web servers, messaging systems, transaction monitors (TMs), and other technologies.
A new graphical tool, WebLogic Builder, which dramatically simplifies assembling, configuring, packaging, and deploying J2EE applications to WebLogic Server. The WebLogic Builder tool catalyzes the process of preparing and deploying applications to the WebLogic Server because it does the following:
Eliminates the need to edit J2EE deployment descriptors by hand
Validates configuration parameters
Retrieves information on databases, JMS destinations, and other objects in WebLogic Server
The EJBGenTool simplifies EJB development by eliminating the complexity of having to work with multiple Java source files. This simplification enables developers to focus on their business functionality and develop the actual EJB implementation class. All the accompanying files are generated by the tool and prepared for further configuration and deployment with WebLogic Builder.
Simplified WebLogic domain and cluster creation and configuration with an easy-to-use graphical configuration wizard—the WebLogic Domain Configuration tool.
The capabilities to support both enterprise J2EE applications (EJBs) and Web applications (servlets, JSP, and static HTML).
A fully integrated and Unified Message Bus (JMS), which is responsible for receiving and distributing messages throughout the WebLogic application infrastructure.
Improved developer and administrator productivity through the following features:
Tight integration with all leading J2EE development tools, such as Together ControlCenter, WebGain Studio, Visual Age for Java, and Borland’s JBuilder
A management infrastructure based on the JMX and SNMP standards for the efficient deployment, configuration, management, and monitoring of production applications, which includes integration with products such as HP-Openview and BMC Patrol
A powerful application infrastructure ecosystem to support other technology solutions required in the real world, such as content management systems (for example, Interwoven, Documentum, and Vignette) and search engines (for example, Verity, Autonomy, and Inktomi).
High-performance server-side Java Virtual Machine (JVM) for the Windows platform: WebLogic JRockit.
In addition to directly leveraging J2EE services and components, users can also develop enterprise applications by using WebLogic Server’s Web services framework, which is built on the J2EE infrastructure. WebLogic Server provides full support for the following Web service standards:
Extensible Markup Language (XML 1.0)—. BEA WebLogic Server implements the latest Java API for XML Processing (JAXP), and includes a built-in Apache Xerces parser and a custom high-performance XML parser specifically designed for small-to-medium XML documents. Also included is a Xalan XSL transformer, BEA XML editor, and enhanced XML Registry capabilities.
Simple Object Access Protocol (SOAP 1.1)—. SOAP is the emerging standard for the exchange of information in a distributed environment. It is the communication protocol for defining the format of data for Web services that are delivered via HTTP.
Web Services Definition Language (WSDL 1.1)—. WSDL is the XML-based language used to describe a published Web service. WebLogic Server has built-in support for WSDL and generates a WSDL script automatically when a Web service is deployed.
Universal Description, Discovery, and Integration (UDDI 1.0)—. A UDDI registry is a distributed Web-based information directory listing Web services. WebLogic Server includes an embedded UDDI registry and an API for searching and updating this or any other third-party UDDI registry.
As discussed earlier, every application server vendor must satisfy two criteria. The first is compliance with the J2EE specification, also known as J2EE certification, as well as other leading Internet standards. The second is the implementation of additional infrastructure services to support the J2EE Application Programming Model (see Figure 9.5), which has the following components:
The presentation layer is responsible for managing the user interfaces of applications, including desktop applications, Web browsers, and pervasive devices.
The business layer hosts the business logic for the application.
The integration layer provides connectivity with enterprise systems, databases, and other application-relevant data sources.
You will find that to support the J2EE Application Programming Model, application server vendors go beyond J2EE to ensure that their application server is the best of breed.
In complete compliance with the J2EE Application Programming Model, BEA WebLogic Server 7 has a three-layered architecture, with reliability, availability, scalability, and other QoS features extended across the presentation, business, and integration layers, as illustrated in Figure 9.6.
The following sections discuss each architectural layer of WebLogic Server as well as the value-added features that continue WebLogic Server’s success in the application server marketplace.
The presentation layer of WebLogic Server is primarily responsible for managing interactions with a broad array of end-user Web applications, which communicate with WebLogic Server through client types such as
Web browsers, also known as thin clients, which send HTTP requests and receive HTTP responses for static HTML or dynamic Web pages generated by Java servlets and JSP.
Thick clients, such as Java, CORBA, and COM+ clients, which communicate with WebLogic Server using RMI, RMI-IIOP, and DCOM, respectively.
Pervasive devices, which include wireless phones, PDAs, smart appliances, and other emerging remote clients that communicate with the server via specific and usually very compact protocols. An example of such a protocol is the Wireless Markup Language (WML), an XML-based language optimized for wireless devices. WebLogic Server can generate WML pages from servlets and JSP.
Note
In interactions in which clients are typically other Enterprise Information Systems (EISs), such as Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Human Resource (HR), and Customer Relationship Management (CRM) systems, connectivity is achieved through WebLogic Server’s integration layer.
WebLogic Server implements the presentation layer through an integrated high-performance Web server, which runs in the same process as the application server, as illustrated in Figure 9.7. It is the Web server that implements the Web container, the execution environment for the presentation J2EE components (servlets and JSP). WebLogic Server also provides native plug-ins for the Apache, iPlanet, and Microsoft IIS Web servers, which enables you to leverage these Web servers to deliver the static content (HTML pages) of your Web application and, hence, distribute the workload of your Web application across the WebLogic and Web server, respectively.
Note
The presentation layer can also be extended to be a Web portal through the WebLogic Portal product, which can then be used to aggregate and share content.
Beyond the basic presentation layer support for Web applications, which primarily involves hosting and serving static or dynamic content, WebLogic Server also provides the following features:
Clustering—. WebLogic Server can be deployed in a cluster of multiple-server instances to achieve scalability and high availability. A WebLogic Server cluster appears to its clients as a single server, but it is a group of servers coordinating their processing as a single “super” server. Clustering provides the capability to fail over from a malfunctioning server to a functioning server, thus insulating clients from hardware or power failures through the elimination of a single point of failure.
High availability with transparent failover—. WebLogic Server enables the data contained in Web components to be replicated across multiple machines. Hence, in the event of a failure, the current client session information is maintained. In addition to disk-based persistence, WebLogic Server can also use a very efficient in-memory replication mechanism for a client’s session state to achieve the highest level of performance and scalability.
Load balancing—. Incoming requests can be distributed intelligently across multiple instances of WebLogic Server in a cluster configuration through load-balancing appliances or by using the WebLogic or third-party Web server as a proxy.
Note
The capability to efficiently load-balance requests is a critical aspect to any failover, scalability, and high-availability solution.
Note
▸ For detailed information on how to design and implement WebLogic Server clustering solutions, see Chapter 25, “Implementing Highly Available and Scalable Solutions Using the WebLogic Cluster,” p. 837.
Virtual hosting—. WebLogic Server can host multiple Web sites in a single application server. For example, organizations sharing a WebLogic server can have different domain names, with Web servers accessible as
www.company1.comandwww.company2.com, without requiring users to know any extra path information.Dynamic page-level caching—. WebLogic Server provides page-level caching for entire JSP pages, static pages, pages generated via servlets, URLs, and other file types, without requiring any code changes to the application. The caching features are enabled via the WebLogic Administration Console. By using the WebLogic JSP cache tags, you can also cache specific portions of a JSP page; this capability was first introduced in WebLogic Server 6.x.
Integrated management—. The WebLogic Web server can be fully managed through the Web-based extensible WebLogic Administration Console.
The business layer of WebLogic Server is responsible for providing the necessary infrastructure services to the business logic components of a J2EE application, which, as defined by the J2EE specification, are represented through EJBs. EJBs are the enterprise Java components that enable developers to build scalable, portable, and reusable server-side business logic.
Three major types of EJBs are defined by the J2EE EJB 2.0 specification:
Session beans—. These beans are process or control objects specific to a particular client and are responsible for controlling workflow, managing processes/tasks, or coordinating processes between entity beans. Session beans can be
Stateless, which execute a request and return a response without saving any state information
Stateful, which are an extension of a client because they perform tasks and maintain state information on behalf of a client
Entity beans—. These beans are data objects that act as nouns and usually represent real-life objects, such as bank accounts, purchase orders, employees, companies, and vendors. They are in-memory objects that physically map to data stored in an underlying relational database or legacy system. Persistence can be manually performed by the developer (bean-managed persistence) or by WebLogic Server (container-managed persistence). Typically, session beans call entity beans to achieve their desired actions, such as a purchase order approval router (session bean) that deals with purchase orders (entity beans).
Message-driven beans—. These beans are messaging objects designed to receive and route messages from clients to other EJBs. For example, a logging service can receive logging messages and call a session bean to perform the actual logging.
As illustrated in Figure 9.8, WebLogic Server implements the business layer through the EJB container, which handles the underlying infrastructure services, such as concurrency, security, availability, scalability, persistence, transaction management, and object life-cycle management.
Beyond the basic EJB support, WebLogic Server also provides the following features to ensure that EJB deployments are robust:
Full EJB 2.0 support—. The EJB container is fully compliant with EJB 2.0; it also supports EJB 1.1.
Dynamic query support—. Dynamic queries enable you to construct and execute queries programmatically in your application code. They prevent the need to hard-code finder queries into an EJB’s deployment descriptor.
EJB WebLogic QL enhancement support—. WebLogic QL is a WebLogic-specific extension of the EJB 2.0 query language known as EJB QL, with support for the following enhancement features:
Message-driven bean migratable service support—. This feature allows the message-driven bean and the JMS server to migrate to another server in the same cluster, which expedites message-driven bean recovery.
EJB CMP multiple table mapping support—. Multiple table mapping enables you to map a single EJB to multiple DBMS tables within a single database.
Optimistic concurrency support—. This feature is a new concurrency strategy offered by WebLogic Server, which provides optimistic support with and without caching enabled for the bean. The bean guarantees that the data is consistent by making sure that it was not modified before committing the transaction.
ReadOnly entity concurrency support—. This feature allows WebLogic Server to activate a separate instance of a read-only bean for each transaction needing concurrent access to that bean.
EJB instance pooling—. This feature allows WebLogic Server to preload a given number of EJB instances and prepare them for use, thereby saving time by not having to create a new EJB instance for each request. When a client is done with an EJB instance, the server puts it back into the pool for future reuse. This feature also helps limit the load on the server by giving the administrator control over the maximum number of beans in the pool.
EJB clustering—. This feature allows EJBs to be deployed into a WebLogic cluster, where each bean can be distributed across the cluster and located by means of distributed naming and directory facilities. Leveraging the clustering capabilities of WebLogic Server enables EJB deployments to benefit from enhanced scalability and reliability.
EJB high availability with transparent failover—. WebLogic Server can replicate the state of EJBs across a cluster of separate physical WebLogic Server processes, creating redundancy in case of failure. WebLogic Server transparently fails over to a backup machine in the cluster in the event of a failure.
EJB load balancing—. WebLogic Server can route requests from remote clients to EJB components by using a predetermined algorithm or custom algorithm. This results in scalability beyond a single machine and, using BEA plug-ins, can work with WebLogic Server’s Web server as well as other vendors’ Web servers.
Combined caching support—. This feature enables you to configure a single cache for use with multiple entity beans.
Relationship caching support—. This feature improves the performance of entity beans by loading related entity beans into a cache and avoids multiple queries by issuing a join query for the related beans.
Bulk insert support—. This feature increases the performance of Container-Managed Persistence (CMP) bean creation by enabling the EJB container to perform multiple database inserts for CMP beans in one SQL statement.
As illustrated in Figure 9.9, the integration layer of WebLogic Server is responsible for providing interprocess communication, messaging, and transactional access integrity to your organization’s EIS. For example, you can use the integration layer to access data and information sources, such as RDBMSs, ERP systems, CRM systems, and mainframes. Alternatively, you can also use the integration layer to integrate your J2EE applications with existing technology investments through JMS, J2CA, and Web services, future-proofing the existing information infrastructure.
BEA extends the integration features in WebLogic Server through the WebLogic Integration product to include a full array of solutions for Enterprise Application Integration (EAI), business-to-business (B2B) collaboration, and Business Process Management (BPM).
The following sections describe the infrastructure services the integration layer of WebLogic Server provides.
WebLogic Server provides connectivity and access to relational databases through Java Database Connectivity (JDBC), as illustrated in Figure 9.10, and supports any database that has a JDBC 2.0–compliant driver. The JDBC driver (jDriver) implements the interfaces and classes of the JDBC API. These standard sets of JDBC APIs enable developers to incorporate database services into their applications and ensure little or no change to the Java data-access code in the event your organization changes its database vendor.
JDBC connections and access to a database can be initiated from the presentation or business layer of WebLogic Server by using JSP, servlets, session beans, or entity beans. However, if your application uses the Model-View-Controller (MVC) design model, you use entity beans to access your database by using one of the following persistence services:
Bean-Managed Persistence (BMP)—. Enables you to manually control your database access by using the JDBC APIs.
Container-Managed Persistence (CMP)—. Enables WebLogic Server to generate the required JDBC code automatically at runtime to access a database, synchronizing the beans’ instance fields with the data in the database.
The benefits of accessing a database by using WebLogic Server are as follows:
WebLogic Server is fully JDBC 2.0 compliant.
WebLogic Server provides a highly efficient RMI driver with row-level caching, which can be used with client- or server-side applications.
Obtaining an initial connection to any database as well as managing the number of established connections can be time-intensive operations. To eliminate these concerns, WebLogic Server can configure connection pools that provide ready-to-use pools of connections to your database. By using connection pooling, WebLogic Server establishes a specified number of connections to your database upon startup. Client- and server-side applications can utilize these connections from a connection pool through a data source on the JNDI tree (the preferred method) or by using a multitier WebLogic driver. When the connection is no longer required, WebLogic Server returns the connection to the pool for another application to use.
In addition, connection pools can be used in the context of a WebLogic Server cluster to provide high availability for database connections.
For single-server configurations, WebLogic Server can use MultiPools, which are groups of connection pools that you can set by using one of the following algorithms:
When an application requests a connection, the MultiPool determines which connection pool will provide a connection according to the selected algorithm.
You can bind a JDBC data source resource into a WebLogic server’s JNDI tree as a resource factory. Using resource factories enables you to map a resource factory reference in an EJB’s deployment descriptor to an available resource factory in a running WebLogic server, which can then be used to obtain a database connection from a connection pool.
You can set up connection pools, DataSources, Tx DataSources, and MultiPools as well as monitor established database connections through the Web-based Administration Console.
The J2EE Connector Architecture (J2CA) enables J2EE components, such as EJBs, to interact with EISs through resource adapters. A resource adapter is a J2EE component that implements the J2CA for a specific EIS, and enables a J2EE application and an EIS to communicate with each other. A resource adapter is analogous to a JDBC driver because they both provide a standard API through which a J2EE application can access a resource outside the application server.
WebLogic Server has a built-in J2CA architecture that is fully compliant with the J2CA 1.0 specification. Resource adapters built on the J2CA 1.0 specification plug into WebLogic Server, as illustrated in Figure 9.11, and provide the underlying integration between an EIS and WebLogic Server through the following contracts and interfaces:
Application contract—. Defines the standard API through which a J2EE component accesses the EIS. This API is the only view that the component has of the EIS.
System contract—. Links the resource adapter to important services the application server provides, such as connections, transactions, and security.
Common client interface (CCI)—. Connects any EIS to an application server.
Using the J2CA eliminates the need for EIS vendors to customize their products for each application server or integration framework. By conforming to the J2CA, WebLogic Server does not require additional custom code to extend its support connectivity to an EIS.
WebLogic Server also provides a number of useful features to ease J2CA programming, such as
Automatic pooling and reuse of connections to existing systems
Integrated security, which enables a user to perform a single sign-on to a J2EE application and allows credentials to be automatically propagated to existing systems
Transaction integration between WebLogic Server and EIS, enabling a J2EE application to involve existing systems in a larger Two-Phase Commit (2PC) transaction
To ensure bidirectional interoperability between J2EE components deployed in WebLogic Server and Microsoft’s COM+ distributed component architecture, WebLogic Server provides a software bridge known as the WebLogic jCOM (or simply jCOM), as illustrated in Figure 9.12.
jCOM is a separate runtime component bundled with WebLogic Server, which implements both COM/DCOM over Distributed Computing Environment (DCE) Remote Procedure Call (RPC) and Remote Method Invocation (RMI) over RMI/IIOP distributed components’ infrastructures.
As illustrated in Figure 9.12, jCOM automatically builds the COM/DCOM proxies and RMI stubs between the two types of interfaces (WebLogic Server and COM/DCOM) and performs the necessary translation, which enables
Microsoft COM clients to access objects in WebLogic Server as though they were COM components.
J2EE components within WebLogic Server to access COM components as though they were Java objects.
With jCOM, applications deployed on WebLogic Server can access data in Microsoft applications, such as Excel and Microsoft Word, as well as communicate with Visual Basic clients.
BEA Tuxedo enables developers to develop, manage, and deploy C/C++ or COBOL applications based on procedural, CORBA, and Application-to-Transaction Monitor Interface (ATMI) programming models. WebLogic Server provides interoperability between WebLogic Server applications and Tuxedo services through the BEA WebLogic/Tuxedo Connector (WTC), as illustrated in Figure 9.13.
The WebLogic/Tuxedo Connector is a built-in component of WebLogic Server and provides bidirectional interoperability with BEA Tuxedo, complete with transaction and security integration.
WebLogic Server includes a flexible and tightly integrated messaging infrastructure called the JMS Server, which implements the Java Messaging Service 1.0.2b API specification. The JMS Server is responsible for receiving messages and distributing them; it also supports the point-to-point (PTP) and publish/subscribe approaches to messaging. The major components of the WebLogic JMS Server architecture, illustrated in Figure 9.14, include the following:
Messages—. The objects that communicate information between JMS clients.
Destination—. An object that a JMS client uses to specify the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called queues, and in the publish/subscribe messaging domain, destinations are called topics.
JMS Producers and JMS Consumers—. JMS clients are applications or components that produce or consume messages to and from a JMS queue or topic, respectively. Any J2EE component can act as a JMS client.
Connection Factory—. An object that encapsulates connection configuration information and enables JMS clients to create an open communication channel (connection) with the messaging system.
Java Naming and Directory Interface (JNDI)—. Destination and connection factories are bound to a JNDI API namespace, which allows JMS clients to perform a JNDI API lookup of connection factories and their destinations.
Persistent storage—. Either a file or database for storing persistent message data.
To provide a reliable, scalable, and high-performance enterprise messaging solution for communicating between asynchronous and heterogeneous resources, WebLogic Server’s implementation of the JMS API includes the following features and enhancements:
A single, unified messaging API exists throughout the WebLogic Platform infrastructure.
Messaging support for applications spans different operating systems and machine architectures.
WebLogic Server’s JMS subsystem can be configured from the Web-based Administration Console or by using the JMS API to override values.
WebLogic Server allows interoperability between JMS applications and other resource managers (primarily databases) by using Java Transaction API (JTA) transactions, which include support for distributed transactions and the 2PC protocol. JMS applications can also participate in transactions with other Java APIs that use JTA, including non-WebLogic XA–compliant message brokers.
Using the Flow Control feature, you can enable a JMS server or destination to slow down message producers when it determines that it is becoming overloaded.
Message multicasting allows the delivery of messages to a select group of hosts by using an IP multicast address.
A database or a file can be used for persistent message storage.
JMS can be used with other WebLogic Server APIs and facilities, such as EJBs, JDBC connection pools, servlets, and RMI.
The WebLogic JMS architecture implements the clustering of multiple JMS servers, which provides the following advantages:
Load-balancing destinations across multiple servers in the cluster.
Clusterwide and transparent access to distributed destinations from any server in the cluster.
Multiple physical destinations that can be configured as members of a single distributed destination set within a WebLogic cluster. Therefore, if one instance within the cluster fails, other instances of the same destination can provide service to JMS Producers and Consumers.
Migratability, which allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion.
However, JMS topics and queues are still managed by individual WebLogic Server instances in the cluster.
The WebLogic Server Messaging Bridge, also known as the JMS Bridge, enables you to configure a store-and-forward mechanism between any two messaging providers. This configuration provides interoperability between separate implementations of WebLogic JMS or between WebLogic JMS and another messaging product, such as MQSeries from IBM.
The Message Paging feature can free virtual memory during peak message load periods by swapping out messages from virtual memory to persistent storage when message loads reach a specified threshold.
Conceptually, a Web service is a self-contained (modular), self-describing, loosely coupled programmable component that can be exposed as a service-oriented system on a network and invoked across the Web (intranet, extranet, or Internet). Web services provide a platform-independent, standards-based means for achieving asynchronous access to applications in a heterogeneous distributed environment. They enable organizations to strengthen their value propositions by revealing their core competencies through a suite of interoperable software solutions, which can exist internally or externally to the enterprise through B2B integration, business-to-consumer (B2C) integration, or Enterprise Application Integration (EAI).
To facilitate this model for connectivity and interoperability, WebLogic Web services use the XML-based SOAP 1.1 and 1.2 for the exchange of information in a loosely coupled and distributed environment. Web services deployed to WebLogic Server are described with WSDL 1.1 and can be registered with a public or private service registry by using the UDDI 2.0 standard. WebLogic Server’s implementation of Web services supports all these standards, as illustrated in Figure 9.15.
Also, in WebLogic Server 7, the Web services container has been enhanced to provide additional flexibility and to ensure interoperability with other key Web service vendors, such as Microsoft .NET.
WebLogic Web services can be implemented by using the following technology components:
Stateless session beans—. These beans, as illustrated in Figure 9.16, provide an RPC-style Web service that results in component operation invocations. SOAP messages contain parameters and return values.
Message-driven beans—. These beans, as illustrated in Figure 9.17, provide asynchronous processing and can be implemented as a JMS consumer, providing a document-oriented Web service. SOAP messages contain documents.
SOAP message handler—. This message handler can be used to intercept a SOAP message in both the request and response of the Web service, enabling direct access to the entire SOAP 1.1 message (headers and attachments). The SOAP handler enables you to implement pre-processing and post-processing of SOAP requests, as illustrated in Figure 9.18.
Serializers and deserializers—. These components convert data between XML representation and Java objects. Because a Web service implementation is written in Java, mapping XML parameters to Java objects is a critical aspect of the Web services container. WebLogic Server provides built-in support for simple Java types that can be directly mapped into SOAP-specified types, as defined in the JAX-RPC specification. For applications that use more complex or user-defined types, the WebLogic Autotyper utility can be used to generate serializer and deserializer classes, as illustrated in Figure 9.19, that handle the conversion at runtime. As input, the WebLogic Autotyper utility accepts XML (or Java) representation of the types and generates the equivalent Java (or XML) representation along with the serializer and deserializer classes.
In general, the programming model for Web services in WebLogic Server is to leverage J2EE components and expose them as Web services.
This approach allows Web services to be built on top of the J2EE support already provided by WebLogic Server, which enables deployed Web services to leverage the infrastructure services provided by WebLogic Server, such as transaction management, security, performance, and reliability.
Additional WebLogic Server support for Web services includes
Connection-oriented point-to-point security for WebLogic Web service operations as well as authorization and authentication of Web service operations.
A ServiceGen Ant task that can automate the steps required to package and deploy Web services as an Enterprise Application Archive (EAR) file to WebLogic Server, as illustrated in Figure 9.20. All deployed WebLogic Web services automatically have a home Web page that includes links to the WSDL of the Web service, the client JAR file that you can download for invoking the Web service, and a mechanism for testing the Web service to ensure that it is working as expected.
A built-in independent UDDI 2.0 registry that can be used to publish your Web services; you can use it in testing your Web service deployments. WebLogic Server can also leverage third-party UDDI registries.
A Web Services Explorer tool, which you can use to search and discover available Web services by querying any UDDI registry.
A new pull parser, which improves the performance of Web services applications by enabling developers to target specific portions of an XML document and avoid the need to parse the entire document, as is the case with SAX and DOM parsers.
Legacy applications that still reside on the mainframe do so because they are deemed mission critical, and the problems associated with maintenance are considered minor when you consider the real-time performance and solid reliability that the mainframe environment delivers. With today’s fast-paced software development requirements, it is very unlikely you will be involved with developing enterprise applications for the mainframe. However, there is a greater possibility that the business transactions of your J2EE applications will require real-time direct integration with existing mainframe legacy applications.
To meet the rigorous demands for fast and flawless mainframe integration, BEA provides the WebLogic Java Adapter for Mainframe (WebLogic JAM), which is a separate product that enables bidirectional, request-response integration between J2EE applications deployed on WebLogic Server and mainframe applications.
As illustrated in Figure 9.21, bidirectional communication between WebLogic-hosted J2EE applications and mainframe applications is achieved through the following WebLogic JAM components:
Figure 9.21. J2EE application and mainframe interoperability enabled using the WebLogic JAM product.
WebLogic JAM Gateway component—. This Java application runs in an instance of WebLogic Server and acts as a gateway to route requests and responses between WebLogic Server and the Communications Resource Manager (CRM). All gateway communications with the CRM use the TCP/IP protocol.
Communications Resource Manager (CRM)—. This component runs on the mainframe and coordinates the flow of data between J2EE applications and mainframe applications. The CRM uses the SNA and TCP/IP communication protocols to communicate with the mainframe and WebLogic JAM Gateway, respectively.
Additional technology features of the WebLogic JAM product include the following:
An easy-to-use Web-based Administration Console enables you to configure and administer WebLogic JAM, which is an extension of WebLogic Server’s Administration Console.
Support is provided for distributed transactions by using the 2PC protocol.
You can generate J2EE EJBs, servlets, or standalone Java clients from COBOL data structure definitions by using the eGen Application Generator development tool.
Data translation is supported between Java, XML, and COBOL mainframe data types, and full Extended Binary Coded Decimal Interchange Code (EBCDIC) conversion is supported as well.
Support is provided for using mainframe security credentials.
Multiple instances of WebLogic JAM can be configured in a WebLogic cluster, providing load-balancing and failover of the integration services provided by WebLogic JAM.
WebLogic JAM seamlessly plugs into WebLogic Integration, enabling mainframe interaction to incorporate advanced process rules and workflow.
Web services hold great promise for solving many integration and computing challenges; however, the technology must go beyond the simple synchronous RPC paradigm and transcend what typically amounts to tight coupling between the implementation and the Web service contract. BEA’s new WebLogic Workshop (WLW) product provides an innovative, best-practices framework for developing world-class enterprise Web services. It provides the following major features for accomplishing this objective:
Conversations—. Realistic and robust integration solutions must allow for latency to bridge heterogeneous call and response times between systems. WLW allows long-running and stateful interactions to be maintained between a service client and provider, across multiple requests.
XML Maps—. Provides a clear separation between a Web service contract and its implementation. This separation promotes loose coupling, which in turn provides extensibility and reduces fragility.
Custom XML Maps—. Enables developers to import XML templates and build Web services that generate business-level documents to be used as units of communication. This feature facilitates the use of coarse-grained interfaces.
Resource Controls—. Developers no longer need to know the intricacies of J2EE resources to use them, such as JMS, EJBs, JDBC, J2CA APIs, or the details of invoking external Web services. WLW Controls shield developers from such plumbing complexities so that they can focus on writing code that delivers business value.
These are the three primary components of Workshop:
Java Web Service (JWS) application files—. This component embodies your Web service definition, its properties, and the resources it interacts with. This Web service definition file is a regular Java file with a file type of
.jws, containing special javadoc-style annotations. A.jwsfile can access resources (such as EJBs, databases, message queues) via Controls, a metaphor for simplifying and hiding J2EE resource interactions, which exist as.ctrlfiles. Both.jwsand.ctrlfiles are inducted as standard Web service constructs under the J2EE technology umbrella, via Java Specification Request (JSR) 181.Visual development environment (VDE)—. This versatile tool enables you to model your Web service (
.jwsfiles) and its interactions with J2EE resources via controls (.ctrlfiles). That is, all your.jwsand.ctrlfiles and their special annotations are generated for you in this environment. An intelligent code editor is provided for developing your business logic. In addition, the VDE automatically generates a test harness for your Web service and generates facilities for use by your Web service clients, such as client proxies and WSDL files.Runtime framework (JWS Container)—. This component is the workhorse that makes it all magically happen at runtime. When your Web service is started and invoked inside the Workshop VDE, this container digests your
.jwsand.ctrlfiles, generates all necessary J2EE components, and deploys them as standard J2EE Web applications. This process, usually a laborious and J2EE–skill-demanding task, is now automatically done for you. These generated Web applications, a combination of J2EE components and JWS components, can be deployed (and even fine-tuned or customized) in any J2EE-compliant and JWS-enabled application server. This container can also, by working in concert with the Workshop VDE, enable you to run, test, and debug your visually authored Web services.
After you have developed a Web service by using the Workshop VDE to produce .jws and .ctrl files and deployed them to WebLogic Server, the sequence of events shown in Figure 9.22 transpires.
When a Workshop-developed Web service is invoked, WebLogic Server receives the SOAP request and hands it over to the JWS Container, which first converts the XML request to a Java request (that is, unmarshaling) by reading the XML Map specification, if any, in the .jws file for that Web service. The request is mapped to the appropriate Java logic in the JWS Container, which might invoke a JWS Control in a .ctrl file. The JWS Container invokes the requested resource via the WebLogic Server J2EE container. When done, execution control and any return objects are then passed back to the JWS Container. If the Web service is asynchronous, a callback method can be specified in the .jws file and invoked. The Java results are then converted to an XML (SOAP) response (that is, marshaling) by using the XML Map specification, if any, and sent back to the service client.
Note
XML Maps are optional, and if no map is specified, a “natural” mapping is supplied in both the marshaling and unmarshaling process, in which the Java declaration matches the message’s contents.
The JWS Container also provides services such as
Asynchronous callbacks
Buffering to help minimize wait times between service client and provider
Handlers that enable asynchrony in J2EE resource requests
In addition, the container and VDE together bring you an instant, write-and-run testing harness for your Web services.
Chapter 32, “Web Services Made Easy—WebLogic Workshop,” discusses this development framework and its features in detail, along with the format of .jws and .ctrl files, step-by-step instructions for setting up asynchronous and loosely coupled Web services, and an end-to-end tutorial for how to develop and test a simple Web service. Remarkably, comprehending this chapter requires no prerequisite knowledge of J2EE (except Java), but in the end you will have created a sophisticated J2EE Web application (Web service)!
The primary purpose of J2EE is to provide a standards-based, flexible, and portable technology framework for developing and deploying Web-enabled enterprise applications. Typically, there is a one-to-one relationship between a Web interface and its associated J2EE application, which implies that as an organization increases the Web presence of its applications, the number of interfaces to those applications also increases in a linear fashion. Taking into account the multiple knowledge- and content-based Web sites an organization might also have, the proliferation of a large number of Web interfaces not only creates the perception of disparate technical ecosystems, but also hinders the collaboration of information and knowledge.
Today’s knowledge workers are quite savvy people, and to perform their work efficiently, require a primary Web interface for all significant applications, information streams, and collaboration initiatives within the organization, for example:
Access to all corporate directories, events, and relevant information feeds (news).
A personalized taxonomy of organizational information and data, which provides an optimal decision-making foundation.
A central launch pad for all relevant Web-enabled applications.
A central collaboration interface for email, tasks, schedules, and group/team communication (such as bulletin boards).
Intelligent document/content/knowledge search capabilities.
In essence, what today’s knowledge workers require is a Web-enabled desktop (interface) similar to the Windows desktop. J2EE alone does not provide this requirement for integrating different Web interfaces and rendering multiple streams of dynamic content seamlessly through a single well-designed Web interface. The only technology solution capable of providing a mechanism for designing and building these more complex Web-based interfaces is using a Portal framework to implement a portal. There are many definitions of a portal; however, the Gartner Group, a leading research firm (http://www.gartner.com), describes it the best in the context of an organization: “A portal provides access to and interaction with relevant information, applications and business processes, by select targeted audiences, in a highly personalized manner.” The key development component of a portal solution is the portlet, which is a reusable component that combines Web-based content, application functionality, and access to resources within the context of a portal page.
A portal allows an organization to provide centralized but personalized content to its users, whether they are employees using an intranet portal or external business partners. For example, an organization could create a portal to give employees access to company news, human resource information, email, and other intranet resources. These resources could very well reside on many different internal and external systems, but the employee is presented with a consistent, customizable interface to these systems through the portal. The organization could also use the portal to give business partners inventory and order-management capabilities, again interfacing with internal systems to supply the information.
The BEA WebLogic Portal product provides organizations with a large set of tools to create enterprise-class portals for a wide variety of end users.
WebLogic Portal consists of libraries and J2EE applications built on top of the WebLogic server. There are four main systems within WebLogic Portal:
Personalization services—. This system provides a wide range of services, including a page transition management system known as Webflow, a rules engine, entitlements, delegated administration, and a unified user profile.
Portal services—. This system includes portlet management and portlet page layout and skins.
Commerce services—. This system provides e-commerce capabilities, including an extensible product catalog, order management, payment management, taxation and credit card processing, discounts, campaigns, and advertisement management.
EBusiness Control Center (EBCC)—. This system assists in developing WebLogic Portal applications.
These subsystems of WebLogic Portal are described in more depth in the following sections.
The personalization services in WebLogic Portal provide a foundation on which to build enterprise portals. These are the main services:
Webflow is a page transition management system that greatly simplifies developing and managing Web-based systems by decoupling page-to-page transition logic from HTML or JSP pages and externalizes it in XML files. Webflow uses input processors, which are specialized Java classes that can carry out complex tasks within the Webflow system. For example, an input processor can be used to do form verification on a page instead of putting that logic into a JSP. Webflow also contains “pipelines” that support transactional business logic. The pipelines can be used across multiple Web applications to implement the same business logic.
A unified user profile (UUP) can leverage data from one or more external sources, such as LDAP or legacy databases, and present that information in a common format.
Delegated administration allows different administrators to manage individual portals. Administrative privileges can be delegated to another user if a particular administrator has the ability to do so.
A rules engine is used by other services to dynamically evaluate a complex rule or set of rules. A rule could be used to grant access to a particular portlet, for example. The rule might state that a user must be in a particular role and the access date must fall within the first week of a month. If these two conditions are met, the user is allowed to see the portlet; otherwise, he is not. The rules engine takes various pieces of information and returns a result to the requester.
An entitlements service uses the rules engine to determine if, for example, a particular user should be allowed to have access to a particular page.
An event engine can fire events to listeners when, for example, a user logs in.
Personalization services, such as maintaining user display preferences, user demographics, and so on, are available.
Portal services help with displaying and managing portlets. Within WebLogic Portal, portlets are traditionally small sections of information within a Web page. Each portlet can display content that may or may not have anything to do with other portlets on the page. Some portlets can be minimized so that only their title bar is displayed, or maximized so that they take up the entire Web page. As part of the portal, users can customize portlets’ layout on a particular page or the color or font they are displayed with. Alternatively, a portal page can be set to look the same for all users of a group and can be customized only by an administrator.
WebLogic Portal includes a complete e-commerce system, which includes the following:
An extensible catalog—. The catalog is based on industry standards and enables customers to use it out-of-the-box, extend it with additional attributes, or replace it completely with a system of the customer’s choice.
A shopping cart—. This component can store and manage the shopping cart content of logged-in users and anonymous users.
An order-management system—. Customers use this system to track and manage orders. The order-management system enables a customer to, for example, mark an order as shipped or partially shipped or cancel an order.
Generalized e-commerce capabilities—. These capabilities include sales tax calculation and credit card processing.
Campaigns and interaction management—. A campaign allows a WebLogic Portal user to display advertising campaigns to a site visitor. For example, if a user placed an item in her shopping cart, an event could be sent to the campaign service. The campaign service would then determine that the WebLogic Portal user wanted to display an advertisement for a related product to the Web site user. This advertisement would then be displayed to the user to encourage her to purchase additional merchandise.
The challenges of e-business have brought integration to the forefront of enterprise planning. Until now, companies have attempted to meet these challenges with custom “one off” solutions, which over time have added to the increasing complexity and made things worse. The result has been an ever-increasing multitude of custom integration points, built from resource-intensive, repetitious coding with little or no integration reuse.
BEA WebLogic Integration provides a standards-based comprehensive integration solution for the following tasks:
Developing and deploying e-business applications.
Integrating e-business applications with already deployed applications.
Designing and managing business processes that span applications and departments.
Integrating B2B relationships among business partners, including suppliers, resellers, and distributors.
BEA WebLogic Integration is a standards-based solution, based on J2EE, the de facto standard for building e-business solutions. It also provides support for World Wide Web Consortium (W3C) standards, such as HTTP, XML, and Web services technologies. Building solutions on a standards-based product has a lot of advantages, as it guarantees a high level of interoperability with applications, Web browsers, and other custom front-end interfaces.
BEA WebLogic Integration is built on the industry-leading, J2EE standards–compliant BEA WebLogic Server that provides the following infrastructure and functionality that are critical for security, fault-tolerance, messaging, and transactions:
Business Process Management (BPM)—. Business analysts use this functional area to design, implement, and monitor complex e-business processes. A business process is a series of interconnected business activities involving various systems, applications, manual intervention, and other processes.
Business-to-business integration—. Multiple partner connectivity options and a process-centered approach to B2B accelerate secure connectivity with business partners and allow changes as relationships evolve. Leading protocols, such as ebXML and cXML, are leveraged.
Data integration—. Through this process, data from disparate systems can be merged and used uniformly by transforming it into a universally acceptable and recognizable format.
Application integration—. The J2EE Connector–based architecture greatly simplifies integrating e-business applications with existing enterprise information systems, such as SAP R/3, Siebel, and so forth.
Future-proofed application portfolios, interoperability with existing technologies, and the capability to accommodate and leverage change are all byproducts an organization can realize if it possesses technical agility. The degree to which an organization is technically agile depends on a number of factors, one of which is application infrastructure.
This chapter has introduced WebLogic Platform 7 as a candidate application infrastructure that can contribute to an organization’s technical agility by providing a single, unified, and extensible standards-based (J2EE) application infrastructure. This infrastructure can be leveraged to develop, deploy, and manage enterprise-class J2EE and Web services applications. This chapter has explained the benefits of considering a single software platform approach and offered an in-depth technical overview of WebLogic Platform’s products—WebLogic Server, WebLogic Workshop, WebLogic Portal, and WebLogic Integration.