Enterprise Architect

Creational patterns

2008-09-18T20:35:00.001-07:00

This design patterns is all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.

Abstract Factory
Creates an instance of several families of classes
Builder

Separates object construction from its representation

Factory Method
Creates an instance of several derived classes
Object Pool
Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
Prototype
A fully initialized instance to be copied or cloned
Singleton
A class of which only a single instance can exist

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

COMMON ARCHITECTURES

2008-07-22T05:50:00.000-07:00

Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole. [Sun Microsystems, Inc.]

Software Architecture
Software architecture is the structure of structures and take away the functions that implement business requirements and what remains is architecture.

Description of a structural framework to help the design of the application.
The description of a development environment and deployment configuration that supports the non-functional requirements of a software application.
A software architect is most active during the early stages of development but must participate during the entire development lifecycle of a product.
Architecture is developed and described somewhere between when a vision for the product is developed and before construction begins.
The software architecture must be baselined (agreed on by all stakeholders) before construction begins because a change in the architecture usually has vast consequences.
Architectural considerations: An architecture can be assessed using the following qualitative measures:
A non-functional requirement is one that is specified for a software system and does not pertain to a business function to be developed in the system.
Non-Functional requirements are usually quality attributes for the software system.
Also called service-level requirements or Quality of Service (QoS) requirements or Non-functional requirements
During the inception and elaboration phases, architect works with defining the quality of service measurement for these QoS reqs.
One has to make trade-offs between these requirements (For example, if the most important service-level requirement is the performance of the system, you might sacrifice the maintainability and extensibility of the system to ensure that you meet the performance quality of service)
1.Scalability
2.Maintainability
3.Reliability
4.Availability
5.Extensibility
6.Performance
7.Manageability
8.Security

Design Principles

2008-03-27T21:03:00.000-07:00

What are Software Design Principles?

Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

Rigidity - It is hard to change because every change affects too many other parts of the system.
Fragility - When you make a change, unexpected parts of the system break.
Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.

Open Close Principle

Software entities like classes, modules and functions should be open for extension but closed for modifications.

OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you’ll prefer to extend it without changing the code that was already written (backward compatibility, regression testing, …). This is why we have to make sure our modules follow Open Closed Principle.

When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them. Some particular cases of this are Template Pattern and Strategy Pattern.

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.

Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework, …) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter, …) and an external module controlling the dependencies will inject the reference to the second one.

By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module. Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they don't use.

This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

Single Responsibility Principle

A class should have only one reason to change.

In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.

Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

Liskov's Substitution Principle

Derived types must be completely substitutable for their base types.

This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.

Liskov's Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy

from http://www.oodesign.com/design-principles.html

SCEA 5 Released

2008-02-06T22:29:00.000-08:00

http://www.sun.com/training/certification/java/scea.xml

SCEA 5 BEta Exam Resources List

2008-02-06T22:27:00.000-08:00

Recommended Readings

UML Distilled - by Martin Fowler

Java Design (Objects, UML, and Process) - by Kirk Knoernschild
Addison-Wesley (2002)
ISBN 0-201-75044-9
Web Services For SOA - sun article

SOA Using Java Web Services (Paperback) - by Mark D. Hansen

Developing Java Web Services:
Architecting and Developing Secure Web Services Using Java - by Ramesh Nagappan, Robert Skoczylas,

EnterpriseIntegrationPatterns

Enterprise Java Beans - by Richard Monson-Haefel

Java Enterprise in a Nutshell - by David Flanagan, Jim Farley, William Crawford, Kris Magnusson

EJB v3.0 spec

EJB v2.1 spec

Core Servlets and JavaServer Pages, Vol. 1 (2nd Edition) - by Marty Hall, Larry Brown

Core Servlets and JavaServer Pages, Vol. 2 (2nd Edition) - by Marty Hall, Larry Brown, and Yaakov Chaikin

Core JavaServer Faces (2nd Edition) - by David Geary, Cay S. Horstmann

Servlet v2.5 spec

JSP v1.2 spec

JSF v1.1 spec

Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition - by Nicholas Kassem, Enterprise

Java 2 Platform, Enterprise Edition: Platform and Component Specifications - by Bill Shannon, Mark Hapner, Vlada Matena, Eduardo Pelegri-Llopart, Larry Cable, James Davidson

Enterprise Blueprints: http://java.sun.com/blueprints/enterprise/

Java EE 5 Performance Management and Optimization (Pro) - by Steven Haines

Design Patterns and Contracts - by Jean-Marc Jezequel, by Michel Train and Christine mingins

Design Patterns - by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch

Core J2EE Patterns: http://java.sun.com/blueprints/corej2eepatterns/, http://www.corej2eepatterns.com/

Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition) - Deepak Alur, John Crupi and Dan Malks

J2EE Blueprints

Java 2 Network Security, by Marco Pistoia, Duane F. Reller, Deepak Gupta, Milind Nagnur, Ashok K. Ramani

Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Managemen

Design Patterns Higer Level Diagram

2008-01-31T22:53:00.000-08:00

Design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

GOF Patterns

2008-01-24T01:11:00.001-08:00

Prototype Pattern

2008-01-10T22:20:00.000-08:00

Intent:
Specifies the kinds of objects to create using a prototypical instance and creates
new objects by copying this prototype.
Description:
The Prototype pattern allows an object to create customized objects without knowing
their exact class or the details of how to create them. The Prototype pattern gives
prototypical objects to an object and then initiates the creation of objects. The
creation-initiating object then creates objects by asking the prototypical objects to
make copies of them.

Benefits:
• Hides the concrete product classes from the client.
• Adding and removing products at runtime.
• Specifying new objects by varying values.
• Specifying new objects by varying structure.
• Reduced subclassing.

SCEA 5 Testing Objectives "DRAFT" -beta

2008-01-07T00:28:00.000-08:00

SCEA 5 Multiple Choice Testing Objectives "DRAFT" -beta

Section 1: Application Design Concepts and Principles

1.1Explain the main advantages of an object oriented approach to system design including the effect of encapsulation, inheritance, delegation, and the use of interfaces, on architectural characteristics.
1.2Describe how the principle of “separation of concerns” has been applied to the main system tiers of a Java EE application. Tiers include client (both GUI and web), web (web container), business (EJB container), integration, and resource tiers.
1.3Describe how the principle of “separation of concerns” has been applied to the layers of a Java EE application. Layers include application, virtual platform (component APIs), application infrastructure (containers), enterprise services (operating system and virtualization), compute and storage, and the networking infrastructure layers.

Section 2:Common Architectures

2.1Explain the advantages and disadvantages of two tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
2.2Explain the advantages and disadvantages of three tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security
2.3Explain the advantages and disadvantages of multi-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
2.4Explain the benefits and drawbacks of rich clients and browser-based clients as deployed in a typical Java EE application.
2.5Explain appropriate and inappropriate uses for Web Services in the Java EE Platform

Section 3:Integration and Messaging

3.1Explain possible approaches for communicating with an external system from a Java EE-based system given an outline description of those systems and outline the benefits and drawbacks of each approach.
3.2Explain typical uses of Web Services and XML over HTTP as mechanisms to integrate distinct software components.
3.3Explain how Java Connector Architecture and JMS are used to integrate distinct software components as part of an overall Java EE application.

Section 4: Business Tier Technologies

4.1Explain and contrast uses for Entity Beans, Entity Classes, Stateful and Stateless Session Beans, and Message Driven Beans and understand the advantages and disadvantages of each type.
4.2Explain and contrast the following persistence strategies: Container Managed Persistence (CMP) BMP, JDO, JPA, ORM and using DAOs (Data Access Objects) and direct JDBC-based persistence under the following headings: ease of development, performance, scalability, extensibility and security.
4.3Explain how Java EE supports the deployment of server-side components implemented as Web Services and the advantages and disadvantages of adopting such an approach.
4.4Explain the benefits of the EJB3 development model over previous EJB generations for ease of development including how the EJB container simplifies EJB development.

Section 5: Web Tier Technologies

5.1State the benefits and drawbacks of adopting a web framework in designing a Java EE application
5.2Explain standard uses for JSP and Servlet technologies in a typical Java EE application.
5.3Explain standard uses for JSF technology in a typical Java EE application.
5.4Given a system requirements definition, explain and justify your rationale for choosing a web-centric or EJB-centric implementation to solve the requirements. Web-centric means that you are providing a solution that does not use EJBs. EJB-centric solution will require an application server that supports EJBs.

Section 6: Applicability of Java EE Technology

6.1Given a specified business problem, design a modular solution implemented using Java EE which solves that business problem.
6.2Explain how the Java EE platform enables service oriented architecture (SOA) -based applications.
6.3Explain how you would design a Java EE application to repeatedly measure critical non-functional requirements and outline a standard process with specific strategies to refactor that application to improve on the results of the measurements.

Section 7: Patterns

7.1From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
7.2From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
7.3Select from a list the benefits and drawbacks of a pattern drawn from the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
7.4Select from a list the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

Section 8: Security

8.1Explain the client-side security model for the Java SE environment, including the Web Start and applet deployment modes.
8.2Given an architectural system specification, select appropriate locations for implementation of specified security features, and select suitable technologies for implementation of those features
8.3Identify and classify potential threats to a system and describe how a given architecture will address the threats.
8.4Describe the commonly used declarative and programmatic methods used to secure applications built on the Java EE platform, for example use of deployment descriptors and JAAS.

SCEA 5 Assignment Objectives "DRAFT"

Section 1: Application Design Concepts and Principles

1.1Document a given system architecture by creating UML diagrams for it.
1.2Explain the main advantages of an object oriented approach to system design including the effect of encapsulation, inheritance, delegation, and the use of interfaces, on architectural characteristics.
1.3Describe how the principle of “separation of concerns” has been applied to the main system tiers of a Java EE application. Tiers include client (both GUI and web), web (web container), business (EJB container), integration, and resource tiers.
1.4Describe how the principle of “separation of concerns” has been applied to the layers of a Java EE application. Layers include application, virtual platform (component APIs), application infrastructure (containers), enterprise services (operating system and virtualization), compute and storage, and the networking infrastructure layers.

Section 2:Common Architectures

2.1Explain the advantages and disadvantages of two tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
2.2Explain the advantages and disadvantages of three tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security
2.3Explain the advantages and disadvantages of multi-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
2.4Explain the benefits and drawbacks of rich clients and browser-based clients as deployed in a typical Java EE application.
2.5Create a logical and physical model of a system infrastructure architecture

Section 3: Integration and Messaging

3.1Explain possible approaches for communicating with an external system from a Java EE-based system given an outline description of those systems and outline the benefits and drawbacks of each approach.
3.2Explain typical uses of Web Services and XML over HTTP as mechanisms to integrate distinct software components.
3.3Explain how Java Connector Architecture and JMS are used to integrate distinct software components as part of an overall Java EE application.
3.4Given a scenario, explain the appropriate messaging strategy to satisfy the requirements.

Section 4: Business Tier Technologies

4.1Explain and contrast uses for Entity Beans, Entity Classes, Stateful and Stateless Session Beans, and Message Driven Beans and understand the advantages and disadvantages of each type.
4.2Explain and contrast the following persistence strategies: Container Managed Persistence (CMP) BMP, JDO, JPA, ORM and using DAOs (Data Access Objects) and direct JDBC-based persistence under the following headings: ease of development, performance, scalability, extensibility and security.

Section 5: Web Tier Technologies

5.1Given a system requirements definition, explain and justify your rationale for choosing a web-centric or EJB-centric implementation to solve the requirements. Web-centric means that you are providing a solution that does not use EJBs. EJB-centric solution will require an application server that supports EJBs.

Section 6: Applicability of Java EE Technology

6.1Given a specified business problem, design a modular solution implemented using Java EE which solves that business problem.
6.2Given a specified business problem, identify and prioritize the main technology risk areas that must be addressed by the technical design and architecture.
6.3Explain how the Java EE platform enables service oriented architecture (SOA) -based applications.
6.4Identify how the Java SE and Java EE platform supports the internationalization and localization of applications.
6.5Explain your rationale for choosing build versus buy for a given Java EE component.
6.6Explain the typical challenges associated with the design and implementation of large scale enterprise software systems and how Java EE technology addresses those challenges.
6.7Explain how you would design a Java EE application to repeatedly measure critical non-functional requirements and outline a standard process with specific strategies to refactor that application to improve on the results of the measurements.

Section 7: Patterns

7.1From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
7.2From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
7.3Select from a list the benefits and drawbacks of a pattern drawn from the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
7.4Select from a list the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

Section 8: Security

8.1Given an architectural system specification, select appropriate locations for implementation of specified security features, and select suitable technologies for implementation of those features
8.2Identify and classify potential threats to a system and describe how a given architecture will address the threats.

Abstract Factory Pattern

2008-01-01T22:52:00.000-08:00

Intent:
Provides an interface for creating families of related or dependent objects without
specifying their concrete classes.

Description:
The Abstract Factory pattern defines an abstract class that determines the
appropriate concrete class to instantiate to create a set of concrete classes that
implement a standard interface. The client interacts only with the interfaces and the
Abstract Factory class. The client is completely shielded from the concrete classes.
The Abstract Factory pattern is similar to the Factory Method pattern, except that it
creates families of related objects and can be considered as a factory of factories.

Benefits:
• Isolates concrete classes.
• Makes exchanging product families easy.
• Promotes consistency among products.

When to use?
You can use the Abstract Factory pattern when:
• The system should be independent of how its products are created,
composed, and represented.
• The system should be configured with one of the multiple families of
products.
• A family of related product objects is designed to be used together and
you need to enforce this constraint.
• You want to provide a class library of products and you want to reveal just
their interfaces, not their implementations.

GOF patterns: Creational

2008-01-01T22:18:00.000-08:00

Creational patterns specialize in abstracting the instantiation process. They help in
isolating how objects are created, composed, and represented from the rest of the
system. There are five patterns defined in this category:
• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Test 310-051 Testing objectives for the Sun Certified Enterprise Architect for J2EE Technology

2008-01-01T04:08:00.000-08:00

Testing objectives for the Sun Certified Enterprise Architect for J2EE Technology include:
COMMON ARCHITECTURES
• Given an architecture described in terms of network layout, list benefits and potential weaknesses
associated with it
LEGACY CONNECTIVITY
• Distinguish appropriate from inappropriate techniques for providing access to a legacy system from Java
technology code given an outline description of that legacy system
ENTERPRISE JAVA \BEANS™
• List the required classes/interfaces that must be provided for an Enterprise JavaBean™ component
• Distinguish between stateful and stateless session beans
• Distinguish between session and entity beans
• Recognize appropriate uses for entity, stateful session, and stateless session beans
• State the benefits and costs of container-managed persistence
• State the transactional behavior in a given scenario for an enterprise bean method with a specified
transactional attributed as defined in the deployment descriptor
• Given a requirement specification detailing security and flexibility needs, identify architectures that would
fulfill those requirements
• Identify costs and benefits of using an intermediate data-access object between an entity bean and the
data resource
ENTERPRISE JAVABEANS™ CONTAINER MODEL:
• State the benefits of bean pooling in an Enterprise JavaBeans container
• Explain how the Enterprise JavaBeans container does lifecycle management and has the capability to
increase scalability
PROTOCOLS:
• Given a list of some of its features, identify a protocol that is one of the following: HTTP, HTTPS, IIOP,
or JRMP
• Given a scenario description, distinguish appropriate from inappropriate protocols to implement
that scenario
• Select common firewall features that might interfere with the normal operation of a given protocol
APPLICABILITY OF J2EE™ TECHNOLOGY:
• Identify application aspects that are suited to implementation using J2EE technology
• Identify application aspects that are suited to implementation using Enterprise Java Beans
• Identify suitable J2EE technologies for the implementation of specified application aspects
DESIGN PATTERNS:
• Identify the most appropriate design pattern for a given scenario
• Identify the benefits of using design patterns
• State the name of a Gamma et al. design pattern given the UML diagram and/or a brief description of the
pattern's functionality
• Identify benefits of a specified Gamma et al. design pattern
• Identify the Gamma et al. design pattern associated with a specified J2EE technology feature
MESSAGING:
• Identify scenarios that are appropriate to implementation using messaging, Enterprise JavaBeans
technology, or both
• List benefits of synchronous and asynchronous messaging
• Identify scenarios that are appropriate to implementation using messaging
• Identify scenarios that are more appropriate to implementation using asynchronous messaging, rather
than synchronous
• Identify scenarios that are more appropriate to implementation using synchronous messaging, rather
than asynchronous
INTERNATIONALIZATION:
• State three aspects of any application that might need to be varied or customized in different
deployment locales
• List three features of the Java programming language that can be used to create an
internationalizable/localizable application
SECURITY:
• Identify security restrictions that Java 2 technology environments normally impose on applets running
in a browser
• Given an architectural system specification, identify appropriate locations for implementation of specified
security features and select suitable technologies for implementation of those features