OCM Java® EE 6 Enterprise Architect Exam Guide (Exams 1Z0-807, 1Z0-865 & 1Z0-866)

Oracle’s most advanced certification program in Java technology is the Oracle Certified Master, Java EE 6 Enterprise Architect. Large enterprise organizations (for example, Wall Street firms) with critical applications and environments are constantly in need of skilled architects. These companies are looking for well-trained and highly experienced specialists to architect their systems, define requirements, and oversee execution. Playing key roles in the enterprise, the architect is involved throughout the system life cycle: analyzing and defining requirements, creating design artifacts for enterprise applications, and overseeing the process. As a part of the certification process, candidate architects are required to demonstrate a range of skills that extend well beyond fundamental or core Java programming. This book will hopefully assist you greatly in that endeavor. The Oracle Certified Master, Java EE 6 Enterprise Architect certification, which we’ll refer to as OCMJEA throughout this book, will set you apart from your peers. This book provides information that you will need to prepare for the OCMJEA exam. To pass the certification exam, you should be familiar with the fundamentals of applications programming and should have some proficiency in Java programming. Additionally, you should know specific enterprise technologies. All of the topics listed next are covered in the book’s chapters and downloadable content:

Basic principles of enterprise architectures

Object-oriented design using UML

Application design concepts and principles

Common architectures

Integration and messaging

Business-tier technologies

Web-tier technologies

Design patterns

Security

Enterprise architecture case study (using UML)

Twenty-plus years into its life, Java is now the technology most commonly used behind the strategic scenes for an enterprise. After years in which Java development seemed to be reserved primarily for Internet applications, larger firms in the corporate world are using Java as the language of choice over C and C++ for most of their new development, including but not limited to mobile applications (for example, a majority of mobile handsets support Java), messaging, back-end night-cycle functions such as corporate “books and records” maintenance, database repair, warehousing, and data capture from external data feeds.

Java’s appeal lies not only in its affinity for network and distributed computing but also in Java’s other qualities, such as ease of programming and cross-platform capabilities (that is, the “write once, run anywhere” promise), garbage collection, as well as the global knowledge base: it is the most commonly used programming language ahead of C, its next closest contender, with all the others far behind.

Widespread Capabilities for Application Development

A large portion of the appeal of Java is the ease with which it allows the creation of web-based, self-service applications that enable customers to do their work and perform other tasks over the Internet through a browser using a laptop or mobile device. Most new applications are HTML5/JavaScript/JSON on the web server front end with Java-based Web Services on the application server back end that run on the company’s web server. Figure 1-1 shows the JEE application server hierarchy.

FIGURE 1-1 The Java Platform Enterprise Edition (JEE) application server is the focal point.

Java isn’t just for e-business. Some are developing Java applications for internal use, occasionally deploying Java clients to employee desktops.

Still, many issues stand in the way of Java Platform Enterprise Edition (JEE) adoption by corporate application development groups. These include concerns about the development environment, the need to locate or train Java developers, and the need to upgrade to the new generation of JEE application servers to take full advantage of the technology. This is where the JEE architect is most needed. The right architect can step into the enterprise to resolve these issues and make the dream of a JEE-based enterprise a reality.

An undercurrent of concern also exists about what Microsoft is doing with its .NET product line and what impact, if any, those actions will have on a development group’s Java plans.

Judging from the Java application server market, however, Java and JEE are here to stay. At the time of this writing, Oracle is again the #1 vendor in the Application Server space for 2012, with a market share of 40.7 percent, according to the March 2013 Gartner “Market Share: All Software Markets, Worldwide, 2012” report (see http://java.sys-con.com/node/2616103). Table 1-1 shows the full JEE 6 specification.

TABLE 1-1 JEE 6 API’s and Current Release

Java Is the Glue That Binds the Application Development Process

Java and JEE application servers are critical to developing and deploying scalable enterprise Java applications. Application servers provide the infrastructure to execute and maintain business-critical applications, especially e-business applications. JEE defines the programming model and provides underlying services such as security, transaction management, and messaging to enable developers to build networked Java applications quickly and deploy them effectively in the distributed world. Figure 1-2 shows the multiple functions of the JEE application server.

FIGURE 1-2 The Java Platform Enterprise Edition (JEE) application server is multifunctional.

A rush to deploy the latest JEE as well as servlet-based application servers (for example, Tomcat) in the business environment is fueling growth. A plethora of application server combinations are being offered on the market today and used in the enterprise environment, with more appearing weekly. However, only a few dominate the market. Three companies—Oracle, IBM, and VMware—claim most of the market, and several other vendors that specialize in market niches claim less than 10 percent each. The application server has emerged as the focal point of the evolving distributed, networked corporate development. The application server acts as middleware, making services necessary back-end connections, running business logic and messaging, and managing functions such as transaction management and security. The latest application servers are adding support for mobile computing and integrated Extensible Markup Language (XML) capabilities.

You can create distributed applications without an application server, but you’ll end up having to build from scratch much of the functionality the application server provides—such as database connection pooling. For example, one of our UCNY, Inc. (www.ucny.com) clients uses Lotus Domino as its web server and does not use an application server. “We’ve already built a lot of the functionality we’d get in an application server,” reasoned the application manager. Long story short, the company is now in the process of porting its applications to IBM’s WebSphere JEE application server.

Companies Increasingly Need the Internet to Compete

Through the next decade, most business transactions will be conducted over the Internet. To make this work on a grand scale, standards are critical. The success of JEE is important because it ensures that the Internet is the most cost-effective medium to use for promoting the services of a business. Conducting business with a user-friendly, reliable, speedy, and attractive set of web pages supported by reliable back-end business logic will make the difference between success and failure in the enterprise business.

The entire business must be Internet enabled. The business site must engage the customers and enable them to conduct transactions without the necessity of human interaction. Moreover, it will feed the organization’s “fulfillment” engine as well as provide a place to go for post-transaction services.

Corporations will need architects to anchor development standards such as JEE to facilitate the construction of websites. These sites will communicate the business objectives of their clients, whether they want to direct functionality to local, national, or international markets.

Development roles are now more important than ever. The architect must work together with other technical and graphic design personnel to ensure that the web pages not only meet the business’s needs but that they also maintain a perfect balance between performance and professional graphics work. The design of each component must follow a standard such as JEE to ensure that the end product looks professional, loads faster, and effectively communicates the company’s business objectives to the world.

Challenges of Application Development for the Enterprise

Timing has always been a critical factor for adopting new technologies, but the accelerated pace inherent in a virtual, information-driven business model has put even greater emphasis on response times. To leverage Internet economics, it is imperative that the architect not only project, build, and display enterprise systems, but that he or she do so repeatedly and in a timely manner, with frequent updates to both information and services. Just as the SQL standard facilitated data access, widespread acceptance and inherited experience with the JEE standard will make it easier for architects to construct enterprise systems. The architect’s principal challenge is one of keeping up with the Internet’s hyper-competitive pace while maintaining and leveraging the value of existing business systems.

In this economic environment, timeliness is critical in gaining and maintaining a competitive edge. A number of factors can enhance or impede an organization’s ability to deliver custom enterprise applications quickly and to maximize their value over their lifetime.

Increasing Programmer Productivity

The ability to develop and deploy applications is a key to success in the information economy. Applications must go quickly from prototype to production, and they must continue evolving even after they have been deployed. Productivity, therefore, is vital to responsive application development. JEE provides application development teams with a set of standard application programming interfaces (APIs)—that is, the means to access the services required by multitier applications and standard ways to support a variety of clients. This can contribute to both responsiveness and flexibility.

In contrast to data access that is standardized and stabilized by SQL, a destabilizing factor in Internet and other distributed computing applications is the divergence of programming models. Historically (in web terms) and progressively, technologies such as Hypertext Markup Language (now HTML5) have provided a front-end mechanism for distributing dynamic content, whereas back-end systems such as transaction processors are based on SOAP/REST Web Services, which act as a façade to such legacy software as IBM Customer Information Control System (CICS), Tuxedo, IBM Message Queuing (MQ), Lotus Notes, and other data access systems. These technologies present a diversity of nonstandard programming models based on proprietary architectures.

With no single standard for application models, it is difficult for architecture, development, and production teams to communicate application requirements effectively and productively. As a result, the process of architecting applications is extremely complex. What’s more, the skill sets required to integrate these technologies is not organized well for an effective division of labor.

Another complicating factor in application development time is the client type. Although many applications can be distributed to web browser clients through static or dynamically generated HTML5, others may need to support a specific type of client or several types of clients simultaneously (for example, mobile devices as well as desktop browsers). The programming model should support a variety of client configurations with minimal consequence to basic application architecture or the core business logic of the application.

JEE enables development to be role oriented. Components are architected by one group, developed and assembled by another, and deployed by still another, which is critical for enterprise-level code control and application governance.

JEE Architecture Must Respond to Consumer Demand

Imagine a multilocation retail business trying to increase its customer base by a factor of 10. How much time and effort would be expended on remodeling storefronts, building new warehouses, and so on, to keep up? Realistically, constant rework would impact the business’s ability to serve its customers.

This holds for businesses in the e-commerce arena as well. The ability to architect applications that scale easily to accommodate growth is critical to achieving the company’s goals. To scale effectively, systems require mechanisms to ensure efficient management of system resources and services such as database connections and transactions. They need access to features such as automatic load balancing without any effort on the part of the application developer. Applications should be able to run on any server appropriate to anticipate client volumes and to switch server configurations easily when the need arises. JEE-compliant application servers such as WebSphere, WebLogic, and JBOSS, for example, provide these features in the form of database pooling, server clustering, and failover functionality.

The Architect Must Be Able to Integrate JEE and Legacy Systems

In many enterprises, the data of value to organizations, also called “books and records,” has been collected over the years by existing information systems. The investment resides in applications on those same systems. The business rules, the procedures, and legacy code all work, perform the business functionality properly, and cost a great deal of time and money to produce. Yes, its hard to believe, but there are RPG, Fortran, Cobol, and many other legacy platforms still in use at the big Wall Street financial firms. The challenge for developers of enterprise applications is how to reuse and capitalize on this value by betting on middleware, which can converse with the legacy systems.

Architects need to use the JEE standard to help application developers by providing standard ways to access middle-tier and back-end services such as database management systems and transaction monitors.

The JEE Standard Promotes Competition and Choices

Today’s agile development environments advance programmer productivity by facilitating the assembly of software components. As JEE is maturing, integrated development environments (IDEs), such as Eclipse, are starting to increase the productivity of developers dramatically. With extensible development environments that allow developers to add open source or purchased components, or so-called “plug-ins,” the competition to enhance the development environment is great. Architects must possess the ability to mix and match solutions to come up with the optimum configuration to accommodate the task at hand. As the vendor application server shakeout continues, freedom of choice in enterprise application development should soon extend from servers to tools to components.

As vendors adhere to and advance the JEE standard, choices among server products will give an organization the ability to select configurations tailored to its application requirements. Much like SQL, the JEE standard provides the organization the ability to move quickly and easily from one configuration to another (for example, SQL: Sybase DB converted to Oracle), as internal and external demand requires.

Access to the proper development tools for the job is another important choice. Development teams should be able to use new tools as needs arise, including tools from server vendors and third-party tool developers. What’s more, each member of a development team should have access to the tools most appropriate to his or her skill set and contribution.

Finally, developers should be able to choose from a market of off-the-shelf application components to take advantage of external expertise and to enhance development productivity. JEE standardization over the coming years will advance systems development just as SQL advanced database development.

Design Goals of JEE Architecture

The web architecture required for JEE is somewhat analogous to the architecture required to run vendor-based SQL database servers. The same qualities of performance, reliability, and security must be present for web application servers to provide a host for an application. Speed is key, and the good architect must find a way to provide it. The competition will win out every time if it is able to provide faster response to the client. The user can click away to a competitor if a response is too slow on your site.

Mastering this requirement is a difficult task for the architect, because the user base can change rapidly. Not only should the architect be concerned with domestic customers and business hours, but he or she must consider the effects of globalization. JEE application servers need to be efficient and scalable. These qualities will pare down the field to those few vendors who can provide the speed to handle a local customer base with thousands of simultaneous hits.

JEE Architects Should Strive for Service Availability

Users want the application to be available 24×7. This is the attraction of doing business on the web, as users don’t have to worry about the doors being closed after hours. Moreover, the advancing global economy has made availability a “must” requirement. The sun is always shining somewhere on potential global system users. Additionally, users want to be able to speak to customer service representatives without having to wait until Monday. In addition to general availability, the reliability of the application server and the application software it runs is critical. Interruption of the business cycle—that is, downtime—is unacceptable. The business depends on the application being up and ready to serve.

JEE architects must provide reliable server configurations (clustering) as well as safe and clear failover procedures. JEE application server architects also must consider privacy issues. They must be able to maintain passwords and logins and to hide sensitive data. The data must be tamperproof, and architects must be able to allow for encrypted communication for sensitive portions of the business transactions.

JEE Architecture and Connectivity to Existing Data

Having been part of the development of mainframe systems that still maintain the “books and records” of large enterprises such as Merrill Lynch, Goldman Sachs, and most of the banks located in New York City, it is easy for this author to understand why some of these systems are still in operation 30 years later. They simply work, and replacing them has been expensive. The problem will meet a tipping point when the knowledge base of developers who know these technologies retires.

Specialized access to enterprise resource planning and mainframe systems such as IBM’s CICS has been provided in JEE through the connector architecture. Because each of these systems is highly complex and specialized, each requires unique tools and support to ensure utmost simplicity to application developers. As JEE has evolved, enterprise beans are able to combine the use of connector access objects and service APIs with middle-tier business logic to accomplish their business functions, as demonstrated in Figure 1-3.

FIGURE 1-3 Java Platform Enterprise Edition (JEE) combines client tier, presentation, business processes, and enterprise connectivity.

Expanded User Definition: Customers, Employees, and Partners

In the past, a desktop was the sole means of interfacing with an enterprise system, but those days are gone. Users today want to connect from virtually anywhere. The access begins during their commute and might continue through the workday and while traveling to remote business sites.

Flexible User Interaction

JEE provides choices for graphical user interfaces (GUIs) across an enterprise intranet or on the World Wide Web. Clients can use desktops, laptops, PDAs (personal digital assistants), cell phones, and other devices. Pure client-side user interfaces can use standard HTML and Java applets. Support for HTML facilitates prototypes and support for a broader range of clients. In addition, JEE supports automatic download of the Java plug-in to add applet support. JEE also supports standalone Java application clients.

For server-side deployment of dynamic content, JEE supports both the Java Servlets API and JavaServer Pages (JSP) technology. The Java Servlets API enables developers to easily implement server-side behaviors that take full advantage of the power of the rich Java API. JSP technology combines the ubiquity of HTML with the power of server-side scripting in the Java programming language. The JSP specification supports static templates, dynamic HTML generation, and custom tags.

Flexible Business Component Model

Since its introduction, the EJB technology has developed significant momentum in the middleware marketplace. It enables a simplified approach to multitier application development, concealing application complexity, and enabling the component developer to focus on business logic. JEE is the natural evolution of EJB technology.

EJB technology allows the developer to model the full spectrum of patterns useful in the enterprise by defining three distinct types of EJB components: session beans, entity beans, and message-driven beans. Session beans represent behaviors associated with client sessions, such as a user purchase transaction on an e-commerce site. Entity beans represent collections of data, such as rows in a relational database, and encapsulate operations on the data they represent. Entity beans are intended to be persistent, surviving as long as the data with which they are associated remains viable. The message-driven bean is the coupling of Java Message Service (JMS) with EJB to create an EJB type designed to handle asynchronous JMS messages.

JEE extends the power and portability of EJB components by defining a complete infrastructure that includes standard clients and service APIs for their use.

The New Architect Role: Comprehensive Skill Set Required

Many changes have occurred in software engineering. The most critical one is the scale of use. Scale obviously has been increasing since the first computers were used in the business world (for example, Wall Street circa 1970). In web and mobile applications, the scale of systems is an especially important issue because you never know exactly how many users will be accessing the services. The use of new wave web applications, especially those in the social media space, require that their design consider scaling and the distribution of software components across multiple servers. For example, because web applications are distributed by nature, the huge increases in load that are typical of Internet-deployed systems tend to make multiple parallel servers necessary, even further increasing distribution. Thus, distribution has created even more need for the architect.

Large-scale, Distributed Enterprise Systems and Integration Risk

As systems move from a single host to large-scale, distributed enterprise systems, the risks and difficulty of meeting project requirements increases. In a system that runs entirely on a single host, all pieces of the system communicate with each other reasonably quickly and at approximately the same speed. In distributed systems, making the right choices about where components are located and how they communicate becomes critical. The importance of these decisions has expanded the need for architects. The architect performs planning for the location of, and the communication among, software components. This role distinguishes the architect from the designer and other programmers. The goal of this planning is to ensure that the system includes a failover process if partial outages occur, performs load balancing, and is scalable when the demand for concurrent use exceeds the original design parameters.

Quality of Service

The architect is primarily concerned with quality of service: ensuring that the performance and reliability of the system provides all users the same service-level agreement (SLA). The architect works with use cases and provides crucial insight into the architectural development, especially with respect to quality of service (QoS).

Nonfunctional Requirements

Another focus of the architect is so-called “nonfunctional requirements.” This focus has become necessary because distributed systems mandate an architectural design that ensures that the system is maintainable and performs sufficiently well even after all the functional requirements are met.

The focus on quality of service is a surprise to many experienced designers. They often find focusing on quality of service to be frustrating, and they want to work with more tangible design aspects. However, experience is proving that as long as a system has a good architecture, other problems are fixable. By contrast, the system lacking a good architecture might be functionally perfect, but still require a total rewrite to be usable or to revise the functionality.

Risk Evaluation and Control

A good architect controls risk to guarantee that the nonfunctional requirements are met by the system design. This means risk control is a project cost, and it must be treated as such.

To make qualified decisions about how much risk control is enough and how much is too much, you evaluate and compare the risks and mitigation strategies based on cost and probability of occurrence. You do not want to create high-cost solutions to mitigate low-probability risks. If designing such a solution was your goal, you could simply design systems that provide T1 connections and mainframes for every client that connects. This is not the best solution, and an architect should not take a position of throw more hardware at it... that will fix all the problems.

The best way to approach the problem is to perform a cost analysis of several options for controlling risk. Some options might be less costly, but leave some risk in place; others might be more costly, but control the risk completely. You can always look at the “do nothing” option: assume that the risk is realized and examine the cost impact. This “pay me now, or pay me later” approach to deciding what architectural solutions fit best is formalized in the return on investment (ROI).

For example, consider the use of a single server to provide availability compared to the implementation of the system on a server cluster. The cost of implementing a single-system environment is significantly less than that of the cluster: usually three to five times cheaper, possibly even more. This savings is due to the number of systems required to create a cluster (two to five or more, depending on the configuration and types of systems used) and the level of expertise required to install and maintain the configuration.

On the other hand, you must consider the cost of lost time and business in the single-system configuration. If the system goes down, how long would it take to replace it? How much money could be lost while the system is being replaced? And how often is the single system likely to fail? This analysis might indicate that, even though the cost of implementing and maintaining a cluster might appear to be more costly at first, the long-term cost of not using a cluster might justify its use.

Technology Responsibilities

The architect is involved with the significant use cases—that is to say, the use cases that need attention because they involve some degree of risk. Perhaps the single most important aspect of an architect’s work is preparing for the unexpected.

The architect is responsible for guiding the development of the architectural prototype. This prototype might be a purely theoretical construction, realized only in documents and diagrams. Or, more commonly, it might involve an element of implemented code. The purpose of the prototype is to develop enough of the final system to determine that the key risks have been successfully addressed.

In developing the architectural prototype, the architect creates the following:

Checklist of assumptions and constraints The architect documents all the assumptions made, so far as they have been recognized. Incorrect assumptions about potentially critical issues, such as user-base growth and transaction volumes, often require the system to be reworked. Documenting these assumptions ensures that you realize as quickly as possible that something is changing that might require such rework. The architect documents all the constraints about the platform upon which the software is constructed and deployed.

Plan for risk identification and mitigation The architect provides a list of known risks, an assessment of the risks, and mitigation plans intended to address the risks.

Descriptive documentation of deployment environment The architect specifies the deployment environment and shows how and where software and service components should be located and how those components should communicate.

UML diagrams The architect uses these diagrams to verify that the architectural prototype supports all the functional requirements. This view of the architectural prototype ensures the domain model is complete enough to enable the architect to map elements of the domain model correctly and to complete the closure of the model.

Management Responsibilities

The architect also has some management responsibilities. The responsibilities generally include some degree of cost management, because other budget holders are not qualified to make decisions about the technologies and risk mitigation approaches. The architect should have soft skills for working effectively with stakeholders and team members.

Excellent interpersonal skills are required for tasks such as the following:

Communicating to other stakeholders the validity of the decisions that have been made. It is likely that many of the stakeholders have preconceived ideas about what technologies should be used in what parts of the system. Many stakeholders tend, quite naturally, to overvalue certain parts of the system that relate to their needs, while simultaneously undervaluing other parts of the system.

Mentoring other team members in the proper use of the technologies that have been chosen to implement a solution.

Building media to describe how the task of selecting technologies was completed. To ensure the technologies are applied correctly, especially when they are new or cutting-edge technologies, the architect oversees the prototype development and uses it as a training tool for lead designers and developers.

Difference Between Architecture and Design

The role of the architect is sometimes hard to distinguish from that of designer. Indeed, the role of an architect is difficult to define. In part, this is because the role varies from company to company, and even from project to project. However, some important generalizations about the architect’s role can be drawn from investigating the common elements of a number of projects.

Although business analysts, system architects, and system designers have distinct roles, the architect often performs many of their functions. This helps to explain the difficulty of defining the architect’s role. In different companies or projects, the architect role might be quite different, depending on exactly which of these additional roles the architect fills.

The architect is not responsible for the project over its entire life cycle. Instead, the architect is primarily involved in the project at the point where its life cycle is moving from the Definition of Requirements phase into the Detailed Design phase. This occurs in the Inception and Elaboration phases. However, the architect must ensure that the final product conforms to the original vision of the architecture model. Some projects request that the architect attend project meetings or critical design reviews throughout the Construction phase.

Architectural Principles

Architecture principles are axioms or assumptions that suggest good practices when constructing an system architecture. These principles form the basis of many architectural patterns and form the decisions an architect makes to satisfy the quality of service requirements.

There are potentially hundreds of architectural principles. However, the next two modules will use the following principles:

Use a client component that depends on an interface to make the software more flexible. This way, the supplier component can be changed or replaced without affecting the client component.

Separate volatile from stable components. As a system changes, you want to reduce the changes to a small number of packages. This principle guides the grouping of components into volatile elements (such as the user interface) and more stable elements (such as the domain entities).

Use component and container frameworks. A component is a software element that is managed by a container. For example, a servlet is managed by a web container. Typically, a software developer creates components. These components are built to fulfill interface or language specifications.

A container is a software framework that manages components built to a certain specification. For example, a web container is a framework for managing HTTP requests and dispatching the requests to a servlet. A container is a system (or library) that you can build or acquire. For example, Tomcat is an implementation of a web container.

A container framework is a powerful tool for the architect. These frameworks enable the architect to purchase software that provides infrastructure for the rest of the software system. This enables the designers and programmers to concentrate on the business logic components rather than the infrastructure.

Keep component interfaces simple and clear. The more complex a component’s interface, the harder it is for software developers to understand how to use the component. Component interfaces should also be highly cohesive.

Keep remote component interfaces coarse-grained. Remote components require network traffic to communicate. You should keep the number of remote requests (which requires sending network messages) to a minimum. Therefore, keep remote interfaces simple and coarse-grained.

Registering for Oracle Certified Master, Java EE 6 Enterprise Architect Distinguishes the Java Professional

Because of the complexities involved, it is becoming increasingly important for IT architects to become an Oracle Certified Master, Java EE 6 Enterprise Architect. With certification, you prove that you are qualified to architect JEE applications. This will hopefully mean opportunities for professional advancement, such as salary increases, job role modifications, and promotions.

The OCMJEA (formerly the SCEA) exam is the ultimate test in the Oracle series. The series currently includes the following certifications:

Oracle Certified Expert, Java EE 6 Enterprise JavaBeans Developer

Oracle Certified Expert, Java EE 6 Java Persistence API Developer

Oracle Certified Expert, Java EE 6 Web Services Developer

Oracle Certified Expert, Java Platform, EE 6 Web Component Developer

Oracle Certified Enterprise Architect (OCMJEA)

For the OCMJEA information, see http://education.oracle.com. The OCMJEE6EA exam tests the concepts you’ve gained as a professional architect. These concepts are typically gained in a career that spans 10 or more years. It includes diverse languages and technology beyond Java. The exam tests your ability to produce an enterprise architecture using JEE. The OCMJEA certification covers the topics discussed in the following sections.

Objectives of the Exam

The objectives tested are listed following each topic. All of these objectives are covered in the chapters that follow.

Application Design Concepts and Principles

Identify the effects of an object-oriented approach to system design, including the effect of encapsulation, inheritance, and use of interfaces.

Identify how the Separation of Concerns principle applies to the component model of a Java EE application, including client, the web and business component containers, and the integration and resource layers.

Identify the correct interpretation of Separation of Concerns as it applies to the Java EE service layers, including component APIs, run-time containers, the operating system, and hardware resources.

Identify nonfunctional and quality of service (QoS) requirements that influence application design, including trade-offs in performance, availability, and serviceability.

Common Architectures

Identify the appropriate strategy for deploying client applications to desktop and mobile platforms, the principles for designing a user interface, and the benefits of applying client tier patterns.

Identify best practices for exception handling, logging, and utilization of business tier patterns.

Identify design patterns that address specific challenges in the web tier, including authentication, authorization, and scaling and clustering to meet demand.

Identify Java EE technologies, including JMS, JCA, and Web Services, and design patterns that address specific challenges in enterprise integration.

Identify the challenges with integrating enterprise resources, the Java EE technologies that address them (including JPA and JDBC), and the communication protocols that support tier-to-tier communication (including RMI, IIOP, and CORBA).

Integration and Messaging

Identify the APIs available for a Java EE technology–based system for communicating with external resources, including JPA, JDBC, RMI, Web Services, JMS, and JCA. Outline the benefits and drawbacks of each approach.

Describe the technologies used to integrate business components with Web Services, including XML over HTTP, JSON, SOAP, and REST.

Identify and detail the technologies used to integrate business components with external resources, including JMS and JCA.

Identify how a Service Oriented Architecture (SOA) facilitates system integration and best practices.

Business Tier Technologies

Identify the correct EJB technology to apply for a given scenario, including entity classes, session beans, message-driven beans, timers, interceptors, and POJOs.

Identify benefits and drawbacks of different persistence technologies such as BMP, CMP, and JPA, including ease of development, performance, scalability, extensibility, and security.

Identify the benefits and drawbacks of implementing Web Services in the EJB component container.

Select the appropriate use of JPA and JPQL in a given scenario.

Web Tier Technologies

Identify the benefits and drawbacks of using URL rewriting and cookies to manage HTTP session state.

Identify appropriate uses for JSP and Servlet technology as well as JavaServer Faces in a given Java EE application.

Identify the benefits of using an EJB container with a web container instead of a web container alone.

Identify the differences between client pull and server push architectures.

Identify the benefits and drawbacks of using a browser to access asynchronous, lightweight processes on the server.

Design Patterns

Demonstrate knowledge of Java EE design patterns, including Service Starter, Singleton, Bean Locator, Resource Binder, Dependency Injection, Payload Extractor, Context Holder, and Thread Tracker.

Select an appropriate pattern for a given application challenge from the following: Facade, Strategy, Observer, Composite, and Abstract Factory.

Identify a design pattern, using a description of its features, from the following: Facade, Strategy, Observer, Composite, and Abstract Factory.

Identify the use of the law of leaky abstractions or a specific anti-pattern in a given scenario.

Select the appropriate pattern for a given scenario from the following Web Services patterns: Web Service Cache, Web Service Broker, Asynchronous Interactions, and JMS Bridge.

Security

Identify elements of the security model in the Java SE environment for remote clients, including Web Start, applets, and the role of the SecurityManager class.

Select appropriate locations to implement Java EE security technologies or features in a UML component and deployment diagram.

Classify the security threats to an enterprise application and select the measures an architect can propose to mitigate them.

Identify techniques associated with declarative and programmatic security, including the use of annotations, deployment descriptors, and JAAS technology.

Identify the security technologies that apply to an application’s code, messaging, and transport layers.

Starting Point

To become an OCMJEA, start at http://education.oracle.com and follow your way to OCMJEE6EA. This presents you with the Oracle Certified Master, Java EE 6 Enterprise Architect Certification path. As the site suggests, we Java developers should all try to move our careers forward.

So let’s start with what you need to do to attain this Oracle Certified Master, Java EE 6 Enterprise Architect Certification (see Figure 1-4). The OCMJEA exam consists of three parts: a multiple-choice exam, an architecture and UML design project, and an essay exam.

FIGURE 1-4 OCMJEA exam steps

The exam is administered by Pearson VUE, a leading worldwide provider of comprehensive technology-based testing and assessment services (see www.pearsonvue.com). Applicants must complete one of the approved courses before taking the exam.

After you have successfully completed one of the designated courses and all three of the exam components, you will have earned the title of Oracle Certified Master, Java EE 6 Enterprise Architect. You can even have your certification listed on the Oracle website at http://education.oracle.com/education/otn/OCMEA.

The exam components and summary details are as follows:

Candidates must complete one of the instructor-led in-class, online, or recorded courses listed next—including Live Web Classes (LWC), Live Virtual Classes (LVC), and Training On-Demand courses—to obtain this certification. Self-Study CDs are excellent study and reference tools but do not meet the course requirement for certification.

Java EE 6: Develop Database Applications with JPA

Java EE 6: Develop Business Components with JMS & EJBs

Architect Enterprise Applications with Java EE

Building Database Driven Applications with JPA

Business Component Development with EJB Technology, Java EE 6

Creating Web Services Using Java Technology

Developing Applications for the Java EE 6 Platform

Developing Web Applications Using JSF Technologies

Developing Web Services Using Java Technology

Java Design Patterns

Java Programming Language, Java SE 6

Java SE 7 Fundamentals

Java SE 7 Programming

Object-Oriented Analysis and Design Using UML

Web Component Development with Servlets & JSPs, Java EE 6

OCMJEA Part 1 Exam 1Z0-807 is currently available at Pearson VUE (pearsonvue.com/oracle) for US$245. There is a course prerequisite. The exam includes 80 multiple-choice, short answer, and drag-and-drop questions. Candidates have 150 minutes to take the exam, and the pass score is 71 percent, up from the 68 percent in earlier versions. See Figure 1-5 for Part 1 test attributes and details.

FIGURE 1-5 OCMJEA Exam 1Z0-807 details

Particular coursework is available that is helpful. See Figure 1-6 for the Part 1 recommended coursework.

FIGURE 1-6 OCMJEA Exam 1Z0-807 recommended course work

OCMJEA Part 2 Exam 1Z0-865 is the architecture and design project, which must be completed via Oracle certification database. You must complete exam 1Z0-807 before completing the project. There is a six-month time limit. The previous versions had no time limit. The passing score is 70 percent, subject to the evaluation of the essay exam and validation of the authenticity of the assignment. The current cost is US$245. See Figure 1-7 for Part 1 master assignment attributes.

FIGURE 1-7 OCMJEA Exam 1Z0-865 details

For example, an assignment might be as follows:

“You are the architect for RemotePharma Corporation, a remote retail pharmacy company with significant operations in the U.S. RemotePharma operates its own pharmacy fulfillment operation to supply and provide discount subscribed drugs and non-subscription products to supplement treatment. RemotePharma has decided to build a web and mobile enrollment and fulfillment system to coop its competitors to effectively pool capacity.”

You are given the following:

A detailed textual description

A domain model

Use cases

Directions on required deliverables

You will have to deliver the following for the system under discussion:

Deliverable 1: Class diagram

Deliverable 2: Component diagram

Deliverable 3: Deployment diagram

Deliverable 4: Use cases (as sequence or collaboration diagrams)

Deliverable 5: Top three technical risks and mitigations for the same

OCMJEA Part 3 Exam 1Z0-866, an essay exam, can be completed at testing centers for a current cost of US$245. To take this exam, you must have passed Parts 1 and 2 and had your assignment validated. You have 120 minutes to complete the essay questions. See Figure 1-8 for the Part 1 master essay attributes.

FIGURE 1-8 OCMJEA Exam 1Z0-866 details

General OCMJEA Test Preparation Tips

To prepare for Part 1, you must understand each of the exam objectives mentioned at the beginning of this chapter and within the chapters that follow. Those with comprehensive experience need only concentrate on their weaknesses. Others with less experience can take anywhere from weeks to months to learn what needs to be known.

As a whole, Part 1 may require that you spend a few hours (for an experienced architect) to six months or more of dedicated preparation (for a beginner).

Part 2 is project work, which requires a lot of focused and concentrated effort. On average, it may require 100 hours of study, typically spread over a period of a few months.

Part 3 is an essay exam on your work in Part 2. Your success depends on your efforts during Part 2. If you did your homework, no special preparation is required at this stage.

Let’s review some test-taking tips:

Prepare summary notes for Part 1. Even though you may have read everything for the exam, having a few summary pages is a good idea. You can do a quick revision of all topics before the exam.

Cramming doesn’t work. If you have followed a study plan, the night before Part 1 you should do a quick review and get to sleep early. Remember that your brain and body need rest to function well.

Approach the exam as you would approach any large task. It might be daunting, but you can do it! A positive attitude goes a long way toward success.

Those tricky problems can knock you off balance. Don’t get frustrated. Reread the question to make sure you understand it, and then try to solve it. If you’re still clueless, mark it and move on. You can come back to it later. What if you have no idea about the answer? Review your options and take your best shot.

The process of elimination can help you choose the correct answer in a multiple-choice question. Start by crossing off the answers that are obviously incorrect. Then spend your time focusing on the potentially correct choices before selecting your answer.

Prepare for scenario-based questions. The test is geared toward testing your architectural skills. Hence, many lengthy scenarios are described, followed by questions that test your knowledge on what technology may be most appropriate in the given situation and why.

Read each scenario question twice. Often the real issues will be embedded within a descriptive situation, and the real question will be hidden. Concentrate on the architecture issues and try to put the scenario to the back of your mind.

They say a picture is worth a thousand words, so when attempting to answer scenario questions, try to diagram what is being described. If, for example, the question is describing a legacy system communicating with an application server, it helps to draw a diagram.

Use scrap paper. Before you start the test, create a grid to represent the questions and your comfort level with the answer. Even when you mark off questions for review, having this in front of you will help you estimate the time required for revision.

This exam tests your architectural abilities, not necessarily your coding ability, so you should focus on the concepts, not on the code. Although the test wants you to know what code performance is, it will not give you a code snippet and ask you to optimize it.