Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
—Antoine de Saint-Exupery
In This Chapter
In search of competitive advantages over their industry peers, organizations are pioneering innovative technical and Web-centric solutions to propagate their intellectual data, information, and knowledge through their network infrastructure to support mission-critical real-time decisions, which can straddle multiple business units.
Without proper foresight and application infrastructure planning to support a growing application portfolio, the adoption of new technologies can quickly generate extremely complex and heterogeneous technical environments, all of which need to be maintained and evolve in parallel with their supported business practices and processes. Depending on the degree of enterprise visibility, applications may also have to integrate with other applications to form a larger business solution suite (an enterprise solution). However, if externalization of business processes has not been planned, integration efforts can be hindered to a point where they are deemed too complex and expensive. This is the dilemma most organizations are finding themselves in, and due to the pace in which technology-based business solutions are originated, constructed, and deployed, this dilemma is ongoing and largely suppressed by an organization’s desire to succeed.
A proven technical solution to this dilemma is the adoption of an interoperable, standards-based application infrastructure that can outlive and support the development, integration, and extension of technical business solutions. Organizations embracing such an application infrastructure approach have increased the overall IT productivity, business value, and longevity of their business solutions, while also lowering any related support cost structures.
Application infrastructure is available in many forms and from many vendors. Realizing what application infrastructure software is the most applicable to your organization is an important issue you must resolve. The ramifications of implementing the wrong application infrastructure are only amplified over time, with the final outcome being that your application infrastructure will eventually cease to support your current and future technical demands.
From a technical perspective, to be competitively prepared to succeed in today’s business climate, an organization must
Expect and accommodate an evolution in technology employed toward implementing business solutions, and leverage this technology in a way to achieve a business value.
It is very common for technical people to get excited about new technologies and business people to perceive new technologies as a risky proposition. For an organization to technically evolve, the business people must expect their technology staff to propose technical solutions that venture into adopting new technologies. Also, the technical staff must accept that proposals on new technology must have a business context which clearly defines the underlying value proposition, risks, and overall cost of ownership of the new technology before it can be accommodated in any business solution.
Leverage existing investment in technology to provide an enhanced return on investment from new technical ventures.
Provide efficient and maintainable mechanisms to allow legacy, custom-built, and commercial systems to coexist with the use of new in-house technology.
Train, evolve, and maintain the internal IT skills to spur a consistent and standards-based approach for solving business solutions.
Provide a mechanism for customers and suppliers to easily experience a value from their business relationships and interactions.
Hide the complexities of the employed technologies so that end users can easily ascertain business value.
Technical agility is the key that opens the door for an organization to realize the preceding success attributes. It also provides a mechanism to inspire and future-proof technical creativity and solutions.
An organization’s technical agility is directly dependent on its technology infrastructure. In the past, infrastructure was a term used to identify the nonfunctional aspects of a business solution—for example, the computing, network, and data storage resources employed toward a business solution. Today, some of the nonfunctional services that were once specific to these types of infrastructures have been embedded as services into vendor-based (off-the-shelf) software solutions. As illustrated in Figure 8.1, these nonfunctional software-based services primarily fall into the following interdependent categories:
Note
Functional services are the specific business processes a business solution is expected to provide and are represented in software as presentation, business, and integration logic.
Scalability—. The capability to maintain a reasonable response time and at the same time allow the business solution to grow (for example, end users, CPU capacity, data storage).
Security—. The capability to provide application- or component-level security mechanisms that can easily be leveraged across integrated business solutions to provide a unified security system.
Compatibility—. The capability to operate with multiple hardware platforms and other infrastructure solutions.
Manageability—. The capability to provide administration, change management control, and root cause diagnostics for business solutions.
Availability—. The capability to meet the accessibility requirements set forth by the service-level agreement of a business solution.
Reuseability—. The capability for the services to be leveraged across multiple business solutions.
These software solutions are primarily server based, and the nonfunctional services they provide enhance their capabilities to optimally support specific aspects of the overall design of a business solution. The following are some examples:
Application servers provide such services as clustering, security, multithreading, concurrency management, session management, and connection pooling to support the execution and management of component-based applications.
Relational database servers provide security, transaction integrity, data clustering, and efficient storage mechanisms for the access, storage, and administration of business data.
Portal servers provide the framework and services to construct and deploy portal solutions that can be the interface to a collection of content-based systems as well as business applications.
Integration servers provide the framework and services to provide intelligent point-to-point business integration capabilities—for example, publish-and-subscribe workflow messaging schemes—as well as data transformation and aggregation to and from multiple data sources.
Management servers provide specific or end-to-end administration and monitoring of the technology infrastructure (application, computing, network, and data) employed toward a business solution and constitute the management infrastructure within an organization.
As more and more business solutions are being developed within a service-based architecture (J2EE or .NET), these types of software solutions have proven to be a critical foundation in their realization. The term used to identify service-based software solutions that serve as the support foundation of one or more business solutions is application infrastructure.
The acquisition of application infrastructure is always an enterprise-level investment because it is schematically engineered to support multiple instances of a specific aspect of a business solution. For example, an application server supports the presentation and business logic related to multiple business solutions, whereas a database server stores the data-centric logic and data related to multiple business solutions. For application infrastructure to contribute to an organization’s technical agility, the return on investment over time needs to be more than just the reuse of its services employed toward multiple business solutions because this approach ultimately only achieves dependency on a specific vendor’s software and loyalty from the perspective of the vendor.
In other words, the application infrastructure software itself must have agility built in for it to contribute to technical agility at the organizational level. Also, the application infrastructure must promote and facilitate enterprise (out-of-the-box) thinking for its organization’s business solutions, and for this reason, the following attributes need to be addressed:
Application infrastructure must not only provide the technology services required to support the construction, deployment, and administration of multiple applications (application portfolio), but also serve as an integration point for legacy, technology variant, and proprietary information systems.
The application infrastructure software must be implemented using industry-accepted and standards-based approaches. So, as new technologies are founded—for example, Web services—and standards evolve to provide a means to embrace that technology or at least integrate with it, there is confidence the application infrastructure solution will have technology longevity and agility built in.
Because a business solution should be resolved in a technology-independent manner (business-driven), the application infrastructure solution cannot afford to be confined to a single hardware platform and must provide mechanisms for easy interoperation with many technologies, network systems, and devices.
Vendors of commercial component-based business solutions must favor the application infrastructure solution as a dominant and certified foundation for their products. This is a good litmus test that your application infrastructure choices are industry aligned and serviceware will always be available if the need arises.
Because an organization’s application infrastructure can be composed of multiple application infrastructure solutions, it is imperative that these solutions are completely interoperable and their impact on each other is completely validated before their introduction.
Keep these application infrastructure attributes in the back of your mind as your learning of application infrastructure evolves throughout this chapter .
It is a well known fact that more IT expenditure goes to “gluing” or even loosely “stringing” applications together than to their actual software development effort. Also, it is very common to see disparate islands of application infrastructure proliferating throughout an organization, creating unique and interoperable application development, deployment, and administration environments, which ultimately hinders application infrastructure reuse. Having multiple, disparate, and non-negotiating application infrastructure environments within an organization defeats the purpose of application infrastructure and is not a strategic direction toward attaining technical agility. But application infrastructure is not a new concept, so why has it not been leveraged to avoid such a landscape?
In general, organizations typically evolve with a few application infrastructure standards. These standards are typically derived from business influences or from the experiences or skills possessed by senior technical staff, and in the short term these standards are closely followed, even for the purchase of vendor-based business solutions. However, information technology history has proven that over time at some point this governance will be broken, potentially leading to application infrastructure chaos within an organization.
This problem stems from the fact that during an application infrastructure standardization effort, little or no emphasis is placed on developing processes for evaluating the current application infrastructure standards against emerging technologies, which is the underlying reason why organizations are slow or incapable of adopting new technologies. Hence, there is no strategic balance between the need for application infrastructure standardization and the opportunity to leverage emerging technologies.
The ramifications for such an imbalance are huge and can surge through an organization like a tsunami. For example, organizations through their respective business units must respond quickly and cost effectively to industry and customer requirements to be competitive. For this reason, the mantra is to always leverage existing application infrastructure investments before investigating new options for resolving a business solution. The danger arises when a time-to-market business solution is required by a business unit and an organization’s current application infrastructure standards will not suffice. At this point, the impetus is to deliver the business solution, implying any inhibiting application infrastructure standards will be sacrificed to implement that business solution if the need arises.
Note
Portal and B2B integration solutions are classic examples in which organizations have invested in binding and proprietary technologies in an ad hoc manner through the lack of organizational application infrastructure standards for emerging technologies.
Over time and with no evolution to the application infrastructure standards, business units will slowly lean toward becoming autonomous IT decision-makers to satisfy their own application infrastructure requirements, which can have the following negative consequences:
The technical environment within and between business units may increase in complexity and heterogeneity.
Stovepipe applications built on nonreusable technology may emerge.
Application integration efforts between business units may evolve in a nonstructured and technologically inconsistent manner.
Business units may become locked into proprietary application infrastructure technologies, which are promoted through cost-saving incentives provided by one or more of the application infrastructure software vendors.
The technical staff required to support the business solutions will either be overwhelmed or just have too much technical focus on their own unique technical environments to be cross-functionally productive.
Eventually, an organization will recognize that the application infrastructures between its business units are becoming diverse, restraining the possibilities of integrating existing business solutions in a cost-effective manner. At this point, the organization is forced to begin a standardization effort again to narrow the application infrastructure technology selection to the most favorable for the current and future organizational needs. Whether a process will be implemented to evaluate the application infrastructure solutions against emerging technologies is debatable.
From the previous sections of this chapter, it is quite clear that for an organization to economically support an evolving application portfolio, an application infrastructure strategy must exist. The right application infrastructure strategy ensures that an organization can accommodate short-term tactical and long-term strategic business considerations efficiently and effectively, the byproduct being the organization’s technical agility.
The difficulty lies in deriving an application infrastructure strategy that will work for your organization. From my personal observations and experiences, in most cases organizations have a habit of identifying application infrastructure solutions in the context of a single business solution. An application infrastructure strategy cannot be based on a single business solution. Also, it must be adaptive to existing technology infrastructure investments within an organization.
The best approach to identifying an application infrastructure strategy that can be adopted by your organization is to assess existing strategies that have been proven successful and are advocated by the leading technical research organizations, such as the Gartner and Meta Groups. These organizations have investigated the topic of application infrastructure in great detail, and their research is based on exposure to many types of technical environments.
Note
The 80/20 rule applies to application infrastructure in the same way it applies to the software development life cycle, where the 80 represents the analysis and design efforts, and the 20 represents the development, testing, and deployment efforts.
The derivation of an application infrastructure strategy is always based on a series of activities, so you have the option to select those activities that will be acceptable culturally and technically, and hence sustainable by your organization. The activities discussed in this chapter have been derived and distilled from an accumulation of research investigating the techniques for deriving an organization’s application infrastructure. As illustrated in Figure 8.2, the application infrastructure strategy proposed in this chapter consists of the following activities:
Recognizing infrastructure patterns, which can be used to resolve business requirements with an infrastructure pattern or combinations of patterns previously identified and defined. An infrastructure pattern describes an end-to-end set of infrastructure components required for a class of applications, encompassing services such as the network, application server, middleware, database server, and storage mechanisms.
Developing a technology taxonomy, which identifies the emerging, critical, inconsistent, and redundant technologies within an organization.
Identifying the Enterprise Application Integration (EAI) types, challenges, successes, and failures within an organization.
For these activities to be conducted, an application infrastructure team must be formed. This team should include senior socio-technical staff as well as IT and application architects from different technology-dependent segments of an organization. The term socio-technical staff refers to people who are qualified to synthesize usability engineering with software design and development. The multidisciplinary skills possessed by socio-technical staff members should include software engineering, human computer interaction (HCI) design techniques, and mechanisms for implementing social frameworks in computing environments. The formation of this team is the first step in creating a visible organizational framework to continually evaluate an organization’s application infrastructure against emerging technologies.
Note
▸ To learn about other social frameworks that benefit an organization’s software development effort, see“J2EE Software Development Methodologies,” p. 35.
In general, a pattern describes a problem that occurs repeatedly in a given environment over time and then describes a solution to that problem in a manner that the solution can be reused for that problem’s context. When this general definition of a pattern is applied to the context of application infrastructure, an infrastructure pattern is the information, knowledge, the “what is” and “how to” that are characteristic to an existing class of applications, which are identified to facilitate solution reuse toward future applications in the same class. In essence, infrastructure patterns are blueprints to how business problems can be cost effectively resolved through the rapid mapping of business requirements to infrastructure designs.
As illustrated in Figure 8.3, an infrastructure pattern captures experience, best practices, and the end-to-end reuse of technology infrastructure for a given type of business pattern.
Referencing Figure 8.3:
The Interface strata defines the primary points of interaction of an application, person-to-system as well as system-to-system.
The Functional strata defines the elements of an application related to data manipulation.
The Physical strata defines all the elements of an application related to physical connectivity, storage, and processing.
The API layer defines the technologies used to provide the application programming interface (API).
The Presentation layer defines the technology used to provide the primary points of interaction.
The Application Server layer defines the software that will execute the business logic.
The Integration Server layer defines the integration software that connects different applications together, reformatting and routing data as necessary.
The Database Server layer defines the RDBMS that will store and provide access to the application data.
The Server layer defines the application server hardware, operating system, and any high-availability solutions employed to support the application.
The Storage layer defines the hardware employed for supporting the RDBMS, including any vendor-based backup and recovery solutions.
The Network layer defines the hardware, software, and any services employed to provide connectivity between the application’s devices.
Infrastructure patterns are typically perceived to be technology driven because their objective is to support the technologies from which business solutions are implemented. However, because technology-based business solutions should always be driven by business requirements as opposed to technology, this also implies that infrastructure patterns should be business driven.
For this reason, to recognize infrastructure patterns, you have to
Observe your business use cases for your organization’s application portfolio.
Categorize the use cases according to a common theme for the type of business problem they are solving.
Extract the following elements that have been applied to implement the associated business application:
Technology infrastructure utilized (physical, functional, and interface)
The challenges, best and worst practices experienced (if available)
The project plan, including the predicted and actual cost model
The types of skills and resources employed
Develop an infrastructure pattern using the elements that are common denominators to a specific type of business application.
The objective for this exercise is to categorize and catalog the infrastructure patterns that coexist within your organization. Even though organizations have unique business application scenarios, you can leverage some common infrastructure patterns proposed by the Meta Group as categorization templates. The following are some examples:
The Transaction category supports business use cases requiring read/write access to data records. This category of use cases can consist of the following types of infrastructure patterns:
Single-tier transactions—. A single-tier batch or online transaction processing (OLTP) application with all processing performed on the host.
Two-tier transactions—. A fat client on the desktop communicating directly with a back-end database server or a Web server that intertwines CGI/ASP/JSP presentation and application logic.
Three/n-tier transactions—. A thin, presentation-logic client communicating with server-based application logic, which in turn communicates with a back-end database server.
The Publish category supports business use cases for read-only access to information and data, such as data warehousing applications and viewing files from a Web browser. This category of use cases can consist of the following types of infrastructure patterns:
Client Server Publish—. A business intelligence fat client, such as a reporting or analysis tool communicating with a back-end database.
Web Publish—. A Web browser interacting over HTTP to enable read-only access to structured documents.
Stream Publish—. The support for one-way real-time publishing of streaming content, such as audio, video, and text to a player client (Windows Media Player, RealAudio clients, and wireless Internet devices).
The Collaboration category supports business use cases for person-to-person communication centered on shared documents or groups of documents, as opposed to strictly data (Transaction category). This category of use cases can consist of the following types of infrastructure patterns:
Real-time collaborate—. Similar to the Stream Publish pattern, but allowing bidirectional transmission of audio, video, chat, and voice versus one-way publishing transmission.
Store-and-forward collaborate—. Supports the ad hoc sharing of documents using the store-and-forward characteristics of e-mail to transfer “attachments” between members of a workgroup or just storing on a shared file server.
Structured Collaborate—. Supports workflow or document management systems.
If you have categorized and cataloged your organization’s application portfolio, you can use the derived infrastructure patterns as a reference or blueprint to develop your future applications. By using an internally recognized and established infrastructure pattern, you can do the following:
Leverage architecture, technology, components, products and the infrastructure configuration to applications that fall into a specific pattern.
Efficiently map business requirements to proven IT business solutions.
Estimate project-related development, implementation, and support costs.
Estimate the length of a software development life cycle.
Comprehend the challenges and skilled resources required.
Embrace any best practices and turn bad practices into learning experiences.
Recognize the skilled resources and responsibilities associated with a pattern.
In general, the role of a taxonomy is to abstract a set of categories that intelligently subdivide and address all areas of a specific subject area. Similarly, a technology taxonomy can be used to categorize and subdivide an organization’s technology. By defining the rules for a category’s membership and its boundaries, the infrastructure team can develop a common syntax and semantics that will be used to classify an organization’s common set of technologies. Alternatively, you can leverage a taxonomy from a technology research organization, where the categories have been preselected for the industry type your organization belongs to. A generic technology taxonomy is illustrated in Figure 8.4.
For an organization to have a successful technology taxonomy, it is important to ensure the taxonomy is stable and not misinterpreted. It can be validated using the following guidelines:
Ensure all the technologies that are relevant to the infrastructure derivation effort are categorized.
Ensure all the boundaries for the technology categories and subcategories are clearly and semantically defined.
Validate whether the category and subcategory definitions will stand the test of time.
Through the development of an in-house technology taxonomy and its technical categories/subcategories, an organization can
Identify major technology trends.
Identify the currently deployed technologies and component architectures and how they are employed toward business applications.
Understand why and when technologies should be combined.
Recognize which technology areas are mission critical.
Much of the application infrastructure to support Enterprise Application Integration (EAI) activities today is focused around preventing application stovepipe and silo scenarios, by enabling business events (transactions) in one application to be available to other applications. However, sharing business events among applications is just one type of integration, and it does not resolve other types of integration voids that are becoming more integral to an overall organizational application infrastructure strategy. The following are additional types of integration:
Analytic integration—. Focuses on getting salient historical information about a business process out of an application and into an analytic infrastructure, such as a data warehouse, data mart, or reporting/analysis tool. All too often, applications come bundled with proprietary tools, databases, and report-builders for analyzing the information gathered within their applications.
Directory integration—. Ensures all configuration, user, and security information used by applications is written, accessed, and updated from an enterprise directory. This type of integration is important today because it is the basis from which an organization can achieve a single sign-on solution as well as a unified user profile administration mechanism.
Content integration—. Enables organizations to share unstructured information (white papers, calendar entries, tasks, e-mails, and so on) across applications.
Portal integration—. Provides access and interaction of relevant information, applications, and business processes to select audiences in a highly unified and personalized manner. Portals present content and business applications in the context of portlets, which are application objects in the portal’s framework. Portlets are typically provided by vendors that specialize in providing a specific business functionality, such as the following:
Robust searches across structured and unstructured repositories
Integration with existing mail and scheduling systems, such as Microsoft Exchange and Lotus Notes
The taxonomy of intellectual properties
Content management and aggregation support
Access to internal and syndicated business-related data feeds
User personalization
Application integration and development within the context of an application services layer (that is, Application Server)
The reason for assessing EAI is that many application infrastructure solutions are available in the marketplace; the objective is to select those that will ease the current and future integration efforts and also be interoperable with each other. The types of integration efforts that your organization can expect to be derived from the previous application infrastructure activities are as follows:
Infrastructure patterns—. Provide a blueprint showing how specific classes of applications have been designed and implemented. Hence, they provide insight into what types of infrastructure patterns will potentially require integration (pattern chain) in the future to meet a specific business requirement.
Technology taxonomy—. Provides an understanding of the types of integration efforts that may arise based on the current technology infrastructure.
The previous sections outlined activities that you could use not only to develop a holistic perspective of the current technologies that have been employed to develop applications in your organization, but also to look over the horizon to what types of technologies, applications, and integration mechanisms could be in line for the future. This information is core to establishing an application infrastructure solution because it allows you to identify
The common stack of application infrastructure solutions (such as application servers, database servers, and directory servers) that a high percentage of your current and, most importantly, the future application portfolio can leverage.
The stovepipe technologies and applications that will render themselves to be labeled inconsistent and hence legacy over time but can be integrated with other applications via application infrastructure solutions to form composite applications.
The emerging technologies that must be embraced to evolve the current application portfolio.
Taking into consideration everything that has been discussed so far in this chapter, the best approach to implementing any application infrastructure solution is to take the software platform approach, where your business applications and their supporting technologies are seen to be part of a related, interlocking software architecture rather than marriages between independent initiatives.
As illustrated in Figure 8.5, a software platform approach involves the following layers:
Platform—. Groups interoperable application infrastructure solutions into their technical domains—for example, application server, databases, and integration servers.
Services—. Shifts the responsibility of certain nonfunctional services from the application domain and into the application infrastructure domain, so it can be shared by multiple applications. The objective of services is to minimize the coupling between the infrastructure and application domains.
Patterns—. Enables business requirements to be mapped to existing infrastructure designs that provide an end-to-end component or service-based solution for a specific class of application. The infrastructure designs are based on the application infrastructure solutions that have been selected to form the platform.
Note
Infrastructure patterns also include a physical infrastructure solution, as illustrated in Figure 8.3. A software platform approach in most cases is hardware, operating system, and network independent.
The software platform approach implies only those application infrastructure solutions that meet the current and future business requirements will be part of the Platform layer. All others will be considered part of an integration initiative. Even though your application infrastructure foundation may be reduced to solutions from a few vendors, perhaps one for each technical domain, there are advantages to taking this approach:
The development and management of business solutions are simplified because the number of technologies that an organization must support is greatly reduced.
The life of existing technology investments is extended because an organization can integrate legacy technology with a modern foundation that developers can use to create composite applications.
The time-to-market of business solutions is accelerated by leveraging skill sets within a focused and proven technology selection.
By adopting a software platform approach, organizations can develop enterprise business applications through a common set of infrastructure services that are connected, aggregated, and presented by a common presentation framework. Each technical domain of the platform must be based on the open standards that exist for that domain, which not only preserves an organization’s investment in that technology, but also enables the technical domains to be interoperable so that composite applications can leverage all the functionality provided by the platform. Also, because the software platform serves as the foundation for multiple mission-critical as well as non–mission-critical operations, all the application infrastructure solutions that constitute the software platform must collectively provide the following Quality of Service (QoS) attributes:
Reliability—. Ensures that applications never “break,” even under the most demanding circumstances.
Availability—. Enables applications that can operate continuously 24×7×365.
Scalability—. Allows companies to cost effectively embrace any level of application usage.
Trusted security—. Enables an organization to maintain complete control of its intellectual properties.
WebLogic Platform 7.0 is a complete middle-tier application infrastructure solution that was developed in response to customers’ demands for a single, unified middleware application infrastructure solution to enable the development, deployment, and management of a diverse array of business solutions and Web services, as illustrated in Figure 8.6.
Hence, the primary objective of WebLogic Platform is to minimize the number of middleware products an organization needs to support, maintain, and integrate. To derive this next generation of middleware, BEA added the necessary infrastructure services and functionality organizations requested into a single software solution, through the extension of its core application server (WebLogic Server) into the areas of integration and portal frameworks.
BEA’s motivating principles for taking this approach were to pioneer the first unified, simplified, and extensible application infrastructure platform for the middle tier. BEA’s definitions for these principles are as follows:
Unified—. An integrated application server, combined with development portal and integration frameworks, unifies the middle-tier application infrastructure solution by providing an integrated suite of software components that form the baseline functionality needed for building enterprise-class business solutions. This single platform also helps organizations lower application delivery costs, meet business needs, and leverage existing infrastructure assets.
Simplified—. The platform simplifies IT operations by providing an integrated framework for developing, debugging, testing, deploying, and managing applications. This framework empowers developers of all skill levels, not just experts, enabling organizations to effectively leverage existing skill sets. Because WebLogic Platform employs fewer technologies with tighter integration and provides a common set of tools for maintenance and deployment, the total cost of ownership of business solutions is drastically reduced.
Extensible—. WebLogic Platform extends the value of existing technology assets by providing tools that help integrate legacy applications across business domains. In addition, the platform itself is extensible through its support of open standards and development tools, enabling developers to build new functionality that leverages the entire application infrastructure platform.
As illustrated in Figure 8.7, BEA WebLogic Platform provides the following application infrastructure functionality through a single software code (SKU) offering:
The Portal Layer—. A framework for presenting information to the user—for example, Web-based user interfaces for content management, personalization, collaboration, and searches.
The Application Server Layer—. The engine for executing business logic. It includes infrastructure for running reusable business components and tools for ensuring reliability, availability, and scalability.
The Integration Layer—. A framework and tools for helping one application communicate with another. Different types of integration include synchronous (immediate) and asynchronous (message-based).
The Security Framework—. A framework for providing access control, directory services, single sign-on, and encryption.
The Operations, Administration, and Management Framework—. Tools that help lower the cost of operating applications. This framework includes tools for maintaining application components, connectivity, and users’ profiles.
Development and Deployment Tools and Methodology—. A framework for developing and customizing applications. It includes programming languages, development environments, modeling tools, and quality and configuration management. There can be different tools for different types of users, including systems programmers, and application programmers, as well as creative and business analysts.
As depicted in Figure 8.8, to deliver these critical infrastructure services with the Quality of Service (QoS) expected by organizations, BEA WebLogic Platform is composed of the following products:
WebLogic Server—. The industry’s most battle-tested and performanceoriented J2EE-compliant application server, which serves as the nucleus of WebLogic Platform. In addition to J2EE, WebLogic Server implements all the significant programming, integration, and networking standards necessary for building real-world business solutions. The following are some examples:
WebLogic Server implements the latest Java API for XML Processing (JAXP) and includes a built-in Apache Xerces parser and a custom highperformance 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.
WebLogic Server supports the Simple Object Access Protocol (SOAP) standard, which 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.
The WebLogic Server has built-in support for WSDL and generates WSDL script automatically when a Web service is deployed on WebLogic Server.
WebLogic Server includes an embedded UDDI registry and an API for searching and updating this or any other third-party UDDI registry.
The distributed management infrastructure of WebLogic Server is based on the open and extensible JMX standard. Also, an SNMP agent is available for compatibility with SNMP-based, third-party management solutions.
WebLogic Server enables applications to incorporate best-of-breed security solutions into its pluggable security framework.
WebLogic Portal—. A framework for creating user-driven Web-based applications through the support of portal foundation services, intelligent administration, integration services, interaction management, and personalization.
WebLogic Integration—. A single, unified platform for executing complex business processes—for example, Business Process Management (BPM), business-to-business integration (B2Bi), and Enterprise Application Integration (EAI).
WebLogic Workshop—. The first Integrated Development Environment (IDE) that dramatically simplifies the development of Web services. WebLogic Workshop enables a broader category of application developers who do not necessarily have J2EE experience but need to rapidly and visually create business logic in the form of reliable Web services.
This chapter provided a unique insight into the topic of application infrastructure by reinforcing the urgency for an organization to embrace a standards-based, flexible, and extensible application infrastructure strategy. It also explained how that strategy can be derived using techniques such as recognizing infrastructure patterns, developing a technology taxonomy, and identifying enterprise application integration (EAI) types.
This chapter concluded with a discussion of the first unified, simplified, and extensible framework for application infrastructure: BEA WebLogic Platform 7.0.