Beginning from Java...

SCEA preparation materials I used

2008-10-06T08:06:00.001-07:00

Just sorting some folders on my laptop =)

Books (links mostly to Amazon.com):
Enterprise Java Beans in Action
O'Reilly. Java Message Service (JMS)
McGraw Hill. SCEA for J2EE Study guide
Mark Cade's SCEA preparation guide
Mastering Java Server Faces
Sun's Core J2EE patterns (pay attention to use second edition of this book!!!
GoF patterns
SOA using Java Web Services
McGraw Hill. Practical J2EE Application Architecture
Mock tests from Whizlabs

Free books and resources:
Mastering EJB. 4th edition
Java Web Start white paper
www.javaranch.com
Sun's Java WS tutorial
Presentations, articles and other resources from the Sun's site about web services, JSF etc. (there are some mock tests by the way)

In conclusion, I'd like to say, that it's better to use not the info from the books but from the official Sun articles or blogs which are numerous enough. Books are just out of date in most cases, especially on the topics concerned with WS or SOA. They can be useful only for gaining basic understanding of the technology.

SCEA Level 1 passed

2008-09-11T14:31:00.000-07:00

Well, SCEA Level 1 is passed. =)))))))))))
It was a difficult test but I coped with it. Main attention was paid to JSP/JSF, WS, and SOA -- in other words, to all relatively new technologies. And really-really-really, my special thanks to those people who created this test because the questions were clever and let me identify some points where my knowledge was weak. However, these points were luckily not so numerous =))
Now, in one or two months I'm going to take and pass part 2 and 3 of the SCEA exam. So, I guess I need a good study in UML and all the related stuff.

I would be grateful for your comments to this post or any of my notes =)

Final post on SCEA: GOF patterns

2008-08-29T00:53:00.000-07:00

Well, this topic is already “stuck in teeth”; however, it’s one of the most important topics on SCEA exam.
I tried not to include in this part of notes the info which is obvious, clear or omnipresent. I just wanted to stress some points which are useful and can be easily remembered.
Some of the examples are adapted from different sources, books, notes and articles including but not limited to:
Applied Java patterns, Stephen Stelting, 2001
Mark Cade’s SCEA preparation guide
Notes from www.leocrawford.org.uk

Creational:

Abstract factory
Main idea: creation of a family of interdependent objects without specifying their concrete class
Drawback: additional classes are needed
Example: An application is creating phone records, each country has got its own rules regarding the format. Common rules are applied by factory while creation, other -- determined at runtime

Factory method
Main idea: defer specifying concrete class created to subclasses
Drawback: additional classes are needed
Example: Connection factories are used by JDBC to connect to EIS's using DAO's

Builder
Main idea: complex object is created from different sources. Algorithm for its creation is independent of both the parts that make up the object and how those parts are assembled
Drawback: tight coupling
Example: Creating an appointment in the calendar. You step by step specify date, reason, participants etc

Prototype
Main idea: a prototype is created which can be copied later by concrete subclasses which specify the details
Example: Cloneable interface; creation of a record, some of fields in which are the same as in another, “base” record

Singleton
Drawback: may present threading problems

Structural:

Adapter
Main idea: integration of incompatible interfaces
Example: EIS

Bridge
Main idea: two separate hierarchies: of abstractions and of implementations
Example: JDBC, JMS, JCA
Improves extensibility; hides implementation detail from clients

Proxy
Main idea: to use a simple object to represent a complex one.
Virtual proxy – if creation of object is too expensive in time or memory, you can postpone it until you really need it
Remote proxy – to hide the fact that you are querying a remote object
Protection proxy – to determine access rights
Examples: Proxy is used in RMI, WS; Session bean may act as a proxy to Entity bean

Flyweight
Main idea: interchangeable instances; application doesn't depend on object identity
May be used when storage costs are high
Drawback: functionality is calculated at runtime which may decrease performance
Example: pooling stateless session beans

Composite
Main idea: hierarchical tree structure of varying complexity with a uniform interface
Drawback: difficult to test
Example: Composite JSP view

Decorator
Main idea: add additional “plug-in”capabilities on the fly without modifying the class hierarchy
Simplifies coding as each feature is implemented in a separate class; enhances extensibility
Drawback: difficult to test and debug
Example: pre/post-processing filters, graphical editors, java IO classes

Façade
Main idea: hide the complexities of a subsystem behind a unified interface
Promotes weak coupling between the subsystem and its clients; translates client requests to subsystem that can fulfill request
Example: Session beans facade

Behavioral

Interpreter
Example: parsers, regex
Efficiency is not critical

Template Method
Fundamental technique for reusing code, allows to avoid code duplication
Main idea: subclasses can specify slight parts of algorithm and behavior

Mediator
Main idea: MOM
Examples: widely used in WS, SOA Enterprise service bus
Another usage: to customize a behavior that is distributed between several objects without using subclasses
Simplifies object protocols

Memento
Main idea: take a snapshot and preserve encapsulation; may provide undo/redo features when used with Command
Examples: 2PC, Stateful session bean passivation

Iterator
Used in Collection API

State
Main idea: Makes state transitions explicit and updatable at runtime; allows avoiding large conditional statements
Drawback: additional classes (each state is represented by its own subclass)

Visitor
Main idea: define a new operation without changing the classes of the elements on which it operates, separate complex algorithms from the object; easy to add new operations
Drawback: may break encapsulation, reduces flexibility
Common usage: object structure contains many classes of objects with differing interfaces and you want to perform operations on these objects that depend on concrete class

Strategy
Main idea: ability to select among different types of interchangeable behavior and algorithms
Pluggable behavior, alternative to subclassing
Example: implementing different sorting algorithms in one class

Observer
Main idea: publish/subscribe model
Is used when an object should be able to notify other objects without making assumptions about their identity
Example: JMS; event handling

Command
Main idea: encapsulate request as an object
Separates the object performing an operation from the one that knows how to perform it
When to use: GUI menus and toolbars; support of logging, undo or transactions
Requests are specified, queued and executed at different times and instances may be shared

Chain of Responsibility
Main idea: object is handled in turn by several dynamically pluggable classes
Commonly used for parsers and event compilers
Reduces coupling, provides pluggable behavior. Allows a set of classes to behave as a whole, because events produced in one class can be set on to other handlers within the composite
Examples: Servlet filters, SOAP message handlers

JSF and JSP

2008-08-27T12:57:00.000-07:00

Benefits of JSF
Hides complexities of Web development by using components
Don’t need to worry about HTTP requests/responses (as in servlets)
MVC separation
Allows to manage UI components as stateful objects on the server
Provides a rich architecture for validation, processing etc.
Allows to create new custom components

The main difference from JSP in that JSF is component-based and JSP is markup-based

Drawbacks of JSF
Bad with search engines (at least, it’s written everywhere =))

JSP lifecycle
1. Translation time. JSP is converted into a servlet. This happens each time JSP is modified.
2. Request time. The resulting servlets is run to generate the page. This happens each time JSP is requested by a browser.

JSF lifecycle
1. Restore view
2. Apply request values
3. Apply validation
4. Update model
5. Invoke application
6. Render response

Scriptlets
Scriptlets are pieces of Java code embedded directly into a JSP page. They are not maintainable, so they should be used only for very simple and non-repeating operations. Scriptlet code may be factored forward into a servlet or converted into custom tag.

Custom tags
Custom tags are present both in JSP and JSF. Custom tags let software developers and Web designers work independently. In other words, a general expectation of custom tags is that they should be used by non-programmers.
Custom tags may be created as JSP or as Java classes since JSP 2.0. They are single-threaded. Attributes of custom tag are fields in class implementing it. Custom tags may introduce caching capability.
Common applications for custom tags are iteration through a collection and providing some layout for the results, representing some custom component combined of several standard components, which is used repeatedly etc.

When to use servlets and when custom tags?
Servlets are better suited for controller and navigation functions and have more limited capabilities. Custom tags are for providing simple access to manipulating business logic or complex components for non-developers (designers etc.).

Managed beans
Managed beans are used for:
1. UI components
2. Form behavior
3. Business objects whose properties are displayed on web pages
4. Configuring external services (data sources, WS etc.)
Managed bean represents Command pattern.
Managed beans usually require introducing some scriptlet code into the view which causes decline in maintainability. However, in general they improve manageability and are easy to understand.
Managed beans are analogous to entities in some way. EJB 3.0 allows Entity beans be used outside a container as POJOs and managed beans respectively.

Patterns in JSF
MVC: JSP + Servlets + managed beans
Composite, Composite View – for JSP templates
Observer: events from the page are sent to all listeners to be processed
Memento: storing form values in Java beans
Façade: Form class may act as a façade hiding bean complexities from JSP client; encapsulates and simplifies access to reusable code
Strategy: Layout Managers which define a family of algorithms and encapsulate each one. This makes those algorithms interchangeable

JSP with XML
Pages may be rendered using XSL/XSLT/XPath processing. This strategy is good for some kind of report generation.
Moreover, JSP may get XML documents to render. However, JSP never directly works on XML data. Some kind of parsing or binding mechanism is

Web services (a laaaaaarge topic) =)

2008-08-22T16:23:00.000-07:00

Why to use WS
WS’s common usage is to integrate heterogeneous applications quickly. They can be integrated across firewalls because WS use HTTP. Primary target of WS are B2B scenarios.
SOA is represented in WS because WS support interoperability and loose coupling. Moreover, services are composable, self-contained and modular, discoverable and dynamically bound.

Document-based vs. RPC-based (procedure-style)
Document-style services are preferred when state maintenance is needed, for validation or when standard XML-schemas are used. They assume transporting an XML document (maybe as an attachment to SOAP message) and having a way to parse it. RPC-based services rely on JAX-WS support of automatic parsing of SOAP messages. Document-style services usually use SAX, StAX. RPC-based can use DOM which causes performance overhead. RPC-based services are synchronous and document-based (message-based) are asynchronous. SOAP supports both.

WSDL-to-Java vs. Java-to-WSDL
WSDL-to-Java approach is preferred if services are written in different languages because it is then easier to define interoperable types. However, it requires good knowledge of WSDL and WS-I Basic Profile. Implementation-first (Java-to-WSDL) approach is easier (don’t need knowledge of WSDL, just generate it) but may cause integration problems after code changes (these changes affect WSDL and, therefore, client).

State
Web Services are stateless in their implementation (Stateless Session bean or Servlet). However, if a stateful business process is needed state may be maintained in front-end, in backend or in service itself. The choice where to maintain state depends on the meaning and durability of data maintained.

Design patterns in WS:
Client-side: business delegate, service locator, proxy
Server-side: adapter, command, web service broker, façade

Examples:
WS-broker: JAXB used for generating DTOs from XML document; JAX-WS code encapsulation
Adapter: an existing system should be exposed as a WS, providing WSDL configs etc. on the basis of current business logic
Command: is used mostly in asynchronous WS.
Façade: access to WS may be provided as a remote session façade
Business delegate: calls the service locator when getting access to a service from client side
Service Locator: UDDI, JAXR etc.
Proxy: a proxy may provide access to several web services when routing requests in ESB; can hide the complexities of using remote objects; JAX-WS dynamic proxies

WSDL
WSDL is a common format for WS description, specifies service signature, protocol and location. WSDL describes services bottom-up, starting with datatypes used and ending with location.
Messaging styles:
RPC/literal
RPC/encoded
Document/literal
Document/encoded
Document/encoded wrapped
Literal means that standard XML schema is used for data binding and parsing; encoded means that custom set of rules is applied for this.
To facilitate interoperability, the WS-I Basic Profile limits the use of the encoding (RPC-encoded or document-encoded) and encourages a literal formatting (document-literal or RPC-literal style). Thus, document-oriented service should use document-literal model etc.

SOAP
SOAP is a common protocol for WS. It is usually run over HTTP or HTTPS but is capable of binding to various transport protocols. SOAP message handlers are used for message encryptions, security, logging, auditing, caching, managing transactions etc. They are introduced declaratively in an XML-file on the server side.

JAX-WS
JAX-WS proxies are dynamic, no stubs are needed.
JAX-WS lets SOAP messages to be generated and parsed automatically. JAX-WS defines Servlet-based (also called JAX-RPC based) and EJB-based service endpoint models. The choice between those two relies only upon whether we are using Web or EJB container for WS requests preprocessing and business logic implementation. Web container doesn’t support concurrency out-of-box. EJB-endpoint also provides more fine-grained, method-level authorization.

JAX-WS 2.0 provides also Dispatch API(client-side) and Provider API(server-side). Those are used for direct work with XML. Dispatch API supports fully dynamic service invocation, no stubs are required.

UDDI and JAXR
UDDI introduces service providers, service brokers and service consumers. Actual content is never stored in UDDI, it’s just a registry. JAXR for registries is analogous to JDBC for databases; it also provides a common API which is independent of underlying registry and adapters for each registry (UDDI, ebXML etc)

Parsing mechanisms
SAX – is used for large documents, allows processing on fly. However, may be used only for message consumption.
StAX – the same as SAX but with writing ability. Moreover, one needs to know the structure of XML document before parsing.
DOM – in-memory tree traversal programming model. Provides random access, reading/writing features, fine-grained control. May be applied with XPath. Platform-neutral and language-neutral.
JAXB – you can’t use it if XML document has no XSD schema (DTD schema is not sufficient). Uses less memory than DOM. Hides XML complexities, however, limits some its features. Lets developers work directly with plain Java classes. Only since JAXB 2.0 Java-to-XML schema is supported. In JAXB 1.0 only XML schema-to-Java approach was supported.
XSLT – provides a standard way for serialization of Java classes into XML. Is higher-level processing model, a complementary one.

DOM, SAX and XSLT are available through JAXP API.

QoS from WS point of view
Reliability. Difficult to achieve because of unreliable transport protocol.
Scalability. Web services scalability may suffer from huge amounts of XML processing. However, introduced asynchronicity may mollify this problem.
Extensibility. WS are extremely extensible because of SOA principles applied in them.
Performance. The main drawback is XML-parsing which is very consuming.
Security. Message-level end-to-end security (data origin authentication). HTTPS (peer entity authentication). However, beside it WS do not have any inherent security; container-managed security can’t be propagated etc.

WS clients and service activation
Stubs – require code generation; are used for services with fairly static interfaces; easy to implement
Dynamic proxy – do not require code generation; are fully supported in JAX-WS; are portable; may decrease performance
Dynamic invocation interface – look-up for a service is performed at runtime; hard to implement; can be used when an incomplete WSDL is provided; slow performance

Asynchronous WS
MDB and JMS may be used to develop asynchronous WS. However, message delivery won’t be guaranteed because of HTTP. Moreover, JMS is only for J2J applications and has problems when passing through firewall.

Persistence

2008-08-19T14:26:00.000-07:00

CMP versus BMP
CMP provides better scalability and extensibility, faster development etc. However, if fine-grained persistence is needed or extreme efficiency is required, BMP would be a better choice.

JPA
The most extensible and scalable. Provides distributed caching in the container. May be used outside the container as simple POJOs. May be even used in J2SE. Provides only optimistic locking.

JDO
Supports OODBMS. Doesn’t support distributed caching out-of-the-box. Provides both pessimistic and optimistic locking. JDOs are also just annotated POJOs.

DAO with direct JDBC and Session Bean as a façade
Is preferred either for extremely small applications with simple persistence logic or when working with huge amounts of simple data which needs to be processed efficiently. Provides better performance but low maintainability.

JSF+JPA
JPA may be used outside the container as POJOs but then one must implement transactions, security etc by oneself. However, it may be ok, if all the work with database consists of simple retrieving of page content

Transactions

2008-08-17T11:33:00.000-07:00

Transactions can be container-managed (CMT) or bean-managed (BMT)

CMT
Mandatory -- transaction must be in effect when the method is called. Otherwise, an exception is thrown.
Required – default behavior. Unless there is already a transaction, container creates new transaction.
Requires new -- container dissociates an existing transaction, if there is one already, creates new transaction, finishes it, and then associates the old one again
Supports -- if transaction context is available, it is used. Otherwise, method is invoked without any transactional context
Not Supported -- if there is a transaction in current thread, container dissociates it, invokes the method and associates it again
Never -- throws EJBException, if there is a transaction associated with a thread. Doesn't create any new transactions

Session synchronized stateful beans support mandatory, required and requires new (TC is needed). Session synchronization is used by stateful session beans to cope with transactional exceptions.
MDB support only required and not supported attributes (not aware of client’s TC)
Stateless session beans support any transactional attribute.

BMT
BMT should be used for transactions in the Web tier because Web container doesn’t support CMT.
BMT provide additional flexibility (for example, a transaction can last several method calls).

JTA supports only flat transactions, not nested ones.
2PC (two phase commit) protocol – support of distributed transactions. Correctness of commit for each persistent store is checked in a centralized way before the commit is actually performed.

Security

2008-08-17T06:26:00.000-07:00

Common threats
• Message alteration
• Confidentiality
• Falsified messages
• Man in the middle
• Principal spoofing
• Forged claims
• Replay of message parts
• Replay
• Denial of Service
• Session hijacking
• Repudiation

Security challenges:
• Identification and authentication
• Data integrity
• Data origin
• Confidentiality
• Message Uniqueness

Implementation
Security may be implemented programmatically or declaratively. J2EE applications are required to support HTTP basic authentication, SSL mutual authentication, and form-based login.

• Application layer security. Provided by component containers. Is fine-grained. However, it is not transferable between applications.
• Transport layer security. Is simple and widely used technology, usually with HTTPS. Tightly couples to transport protocol. Drawbacks: all-or-nothing protection (only some parts of message can’t be protected); point-to-point, not end-to-end security. Is applied for not large amount of systems communication.
• Message layer security. End-to-end security. Is independent of protocol. However, performance may be reduced because processing is complex. Parts of messages may be secured. This type of security is commonplace in WS.

Signing, CA, public and private keys, and related stuff
When one signs a jar using a private key, he puts the public key into it. To verify the owner of current pair of keys, CA is needed. The certificate is also placed in jar. However, you can’t be 100% sure about the real owner of the code inside. Signed jar can’t be modified, no classes can be added etc.

Applet Security
There are 2 ways to make an applet trusted: to sign it or to put it into classpath directory of the program you are using to run it.

Applets may be loaded in two ways: from the net and from classpath directory. Applets loaded over net are passed through byte code verifier which checks that classes conform to Java language. Classes loaded through classpath are granted extremely wide range of rights: they are allowed to read and write files, load libraries on the client, execute processes, exit JVM etc.

Unsigned applets run in an applet sandbox. They are prevented from reading/writing files on the client, connecting to other hosts except that from which they were downloaded, manipulating other threads, starting other programs and using JNI, reading certain system properties, changing any properties, circumventing SecurityManager. No files can be stored on client, but they can be stored on server.

Sandbox model doesn’t protect from DoS attacks because an applet can use any amount of memory

Trusted applets may be permitted to read and write files, connect to sockets, communicate with devices etc. Concrete set of permissions is specified by security policy.

Java Web Start security
Java Web Start provides a compromise between ease of distribution of applets and power of applications. It is downloaded once and then can be run on the client and perform all the required updates etc.
JWS sandbox is more flexible than applet sandbox in that it allows reading or writing files on the disk, accessing printers etc. under user’s control. With user permission JWS may gain control not only to JNLP but to whole Java API. Drawback is that it’s an “all-or-nothing” approach.

JAAS
Is commonly used with J2SE, its scope is limited to a single JVM. Overlaps J2EE declarative security in some points. JAAS enables to perform authorization based not only on the code location but also on the user identity (user-centric model). Code-centric model is better suited for browser-based applications. JAAS may be used in J2EE application to customize the security of an individual application using pluggable LoginModules. JAAS also is pluggable and allows you not to care which underlying security system is used.

WS-Security, XML encryption/ XML Digital Signature
The intent of WS-Security standard is the ability to move security-related info with the message itself. It describes the usage of XML encryption/ XML Digital Signature. These two provide message-level security and allow securing only parts of messages thus promoting SOA. Differences between cryptographic algorithms used with WS-Security are well described here: http://grids.ucs.indiana.edu/ptliupages/publications/WSSPerf.pdf (not sure that it’s so important for the exam but some forums told it is)

SAML
SAML is an XML-based framework, which may be applied to provide for communicating user authentication data. It simplifies single sign-on and distributed transactions. SAML allows business entities to make assertions about the identity of a user. Alternative to cookies but transferable between DNS domains. Is used with web services. Protected from replay attacks by requiring the use of HTTPS.

J2EE patterns – Business tier patterns

2008-08-14T13:46:00.000-07:00

This part of notes is, of course, relied heavily on and is widely using info from Core J2EE Patterns book. If any copyright issues occur, it may be removed.

Business Delegate
Business Delegate is a client-side proxy to remote service which decouples business and presentation tier and has usually a one-to-one relationship to Session façade. It shields client from business logic code changes and handles exceptions. Business Delegate is less widely applied in EJB 3.0 because of dependency injection. Business delegate doesn’t reduce the number of network calls because physically it is located in presentation tier. Increases maintainability, availability (can make automatic recovery without exposing the problem to the client, handles exceptions), performance(caching). It is usually used together with Service Locator pattern. Perfectly fits to B2B environment which use XML technologies.

Session Façade
Is used to hide business tier complexity, reduce the complexity of client code, and provide coarse-grained access for clients. Introduces loose coupling, decreases network traffic. Session façade is used to expose Application Services, Business Objects and Composite Entities to clients. Improves manageability (centralized security management, transaction control). May be stateless or stateful. Session façade is usually unnecessary if EJB aren’t used. Example: Session beans act as a façade to entity beans.

Value List Handler
Manages query execution, results caching and results processing, provides lists of dynamically constructed Transfer Objects by accessing the persistent store at request time. Provides caching, improves network performance. Allows deferring entity bean transactions. Used with DAO promotes separation of concerns. May be implemented as a stateful session façade. Example: maintain search results on the server side; search and iteration functionality.

Service Locator
Encapsulates service lookup and creation. Improves performance (both client performance by caching and network performance by decreasing number of client lookups). Became obsolete with dependency injection. Abstracts complexity and provides code reuse. Creates a single point of control. May be used by many clients. Example: Business Delegate locates a Session Façade; JMS queues and topics location; WS location.

Transfer Object
DTO is used to carry multiple data elements across a tier. Facilitates data exchange, improves response time. DTO makes interfaces more coarse-grained. If entity itself is used as DTO, code duplication is reduced. Drawbacks are issue with stale objects, synchronization and version control. The pattern became quite obsolete after EJB 3.0 but still may be used in some issues. Example: an entity contains a huge number of fields, but a method really needs only several of them.

Transfer Object Assembler
Prevents implementing business logic in the client, minimizes network overhead, reduces coupling. May be implemented as POJO or as Stateless Session Bean. Improves client performance (everything is assembled at the business layer). Difference from Composite entity: DTO Assembler combines DTOs from different sources, Composite Entity may create DTO from its own data. Problems and example are the same as for single DTO.

Application Service
Centralizes reusable business logic across business tier components and services, provides background logic and architecture for Service facades (Session Facades which may use either POJOs or session beans), simplifying them. Avoids code duplication by extracting reusable logic, increases maintainability, introduces additional layer. May provide an intermediary function between presentation and business tier in non-EJB applications; access to email system, legacy system, WS. Example: Session Façade receives method calls, delegates their processing to Application Service. This service makes calls to any Business Objects, Web service broker, DAO, etc.

Business Object
Separates business data and logic, being an object, which contains business logic and business state. Business Object may act as a façade to the objects it encapsulates. Promotes reuse, and increases maintainability. If application isn’t sophisticated, one can expose Business Objects directly to clients; otherwise, they should be used with Session Façade and Application Service. Promotes SOA (different services may be built on the top of Business Objects). It’s, however, overkill for small projects. Without Application Service Business Objects may get too heavyweight and bloated. Example: Business Objects usually represent such entities as Order, Customer, etc. They may be implemented either by POJOs or by Entity beans.

Composite Entity
Composite Entity is used to decrease the quantity of entity2entity queries. It is commonly used with Lazy Loading strategy, which helps to decrease network overhead. It is usually implemented by a parent Business Object and a set of its related components. Composite Entity improves maintainability and performance, makes entities more coarse-grained, reduces database schema dependency (hides the mapping). Example: a set of interrelated Entities act as a whole, being queried and updated together.

J2EE patterns – Integration tier patterns

2008-08-14T13:43:00.000-07:00

This part of notes is, of course, relied heavily on and is widely using info from Core J2EE Patterns book. If any copyright issues occur, it may be removed.

Web Service Broker
Provides access to services through XML and web protocols by introducing a new layer. Performance might decrease. Possible implementation strategies may include JAXB, JAX-WS, custom XML parsing etc. Example: you’ve got several WS written in different languages and you want to separate access code and mechanisms, choose only some required capabilities of their business interfaces, apply additional binding, formatting, parsing etc.

Domain Store
This pattern is needed to separate persistence from your object model and avoid putting persistence details into business objects, which makes persistence transparent. Domain Store can be extremely effective with JDO or JPA. However, this pattern may be bad for a small project because implementing persistence framework by oneself is a complex task which should be judged very well. Another benefit: improved testability. Example: you’ve got a web-based lightweight application, where entities are used outside EJB-container. You need to implement persistence of a business model objects somehow. Entities have complex relationships, inheritance etc.

Service Activator
Is used to invoke services, POJOs or EJBs asynchronously, to integrate pub/sub model. Not obvious point: it is used “to perform a business task which is logically composed of several business tasks” which may be run in parallel and require huge amount of processing. Service Activator may be also implemented as a standalone JMS listener. Example: an MDB receives messages from clients asynchronously and invokes the services required.

Data Access Object
Separates data access code, provides transparent access to data, and abstracts data sources. DAO reduces code complexity in clients by separating persistence layer, reduces coupling, enables transparency etc. Simplifies database migration, provides uniform API for data access. Drawbacks: extra-design of DAO-hierarchy is needed; introduces complexities in design of a “bridge” between OO-model and JDBC RowSets. Commonly used with direct JDBC persistence strategy; in other case, Domain Store is used. Example: an application which is connected to several different databases. Persistence logic shouldn’t be intermingled with business logic but separated in an additional layer.

J2EE patterns – Presentation tier patterns

2008-08-13T00:15:00.000-07:00

This part of notes is, of course, relied heavily on and is widely using info from Core J2EE Patterns book. If any copyright issues occur, it may be removed.

Intercepting Filter
Facilitates pre- and postprocessing of a request, centralizes control, improves reusability, provides flexible configuration. Examples: loosely coupled SOAP message handlers; enqueueing different kinds of security, logging etc. filters in a chain to process a request; Acegi security implementation.

View Helper
Allows encapsulating business logic related to view content but not related to presentation; processes the business data. Fat clients and scriptlets are avoided; better reusability and role separation are provided. Improves maintainability. Java bean helper strategy is usually preferred to custom tag helper strategy because beans are more manageable, so less amount of code is required. However, custom tags are better when dealing with data formatting and flow control. Example: pattern should be used if scriptlets code embedded into JSP becomes too complex.

Front Controller
Manages the handling of a request, including security services, delegates business processing, selects appropriate view, handles errors in a centralized way. Lets to avoid replication among many views, reduce the number of scriptlets. Servlet-front strategy is usually preferred to JSP-front strategy. Example: the application needs a centralized point of entry on the presentation layer which will later delegate responsibilities to other helpers and controllers. This point of entry will provide initial request handling and dispatching.

Application Controller
Is used to centralize and modularize action and view management. Improves reusability. Front controller usually delegated responsibilities to Application controller in more complex applications. Example: a controller which is managing custom handling of SOAP messages and is using SAAJ.

Context Object
Allows avoiding protocol-specific info outside of its relevant context, reduces coupling. May be used for communication between front controller and application controller. Improves reusability, testability and maintainability. Reduces constraints on interfaces (they are less tied to protocol-specific details), reduces performance (state is transferred). Example: security context which contains details about user authentification mechanism.

Service to Worker
It is a combination of front controller, view helper and dispatcher, and main point is business logic, not view. Therefore, controller and dispatcher have more responsibilities, and view is just shown simply after having processed business data. Improves maintainability, code reuse etc. Used with Servlet-front strategy. Example: You’ve got a complex application with sophisticated business logic. However, a client can see only several JSP-pages with buttons and input fields.

Dispatcher View
It is a combination of front controller, view helper and dispatcher, and main point is business view, not business logic. So, content retrieval and error handling are deferred until view processing. This strategy has a drawback: poor separation of business and presentation logic; but if business logic is simple and view processing is complicated, it is ok. Used with JSP-front strategy. Example: You’ve got a site of a design studio, full of complex layouts, animation, etc. The business logic, however, is very straightforward: just several CRUD operations.

Composite View
Creates an aggregate view from modular and atomic components. May be carried out by Java beans (not elegant, because scriptlets are introduced, but requires small amount of upfront work), custom tags (best and preferred strategy), standard tags (like jsp:include, not flexible) or XSLT. Improves code reuse etc. Both enhances and reduces maintainability (there are more components to maintain but all changes are centralized). Reduces performance (view generation at runtime). Example: pages are modular and contain many subviews which repeat throughout the application

MDB, JMS, JCA and Legacy Connectivity

2008-08-10T09:55:00.000-07:00

MDB

MDB – stateless asynchronous message consumer.
The only way to work with it is through messaging system, not directly.
MDB do not have remote or local interfaces because they aren’t RPC-components.
MDB provide a pull-model model of load-balancing which is more effective than push-based model of entity and session beans. Pull-based model is a model when each instance of MDB pulls “work” from the client when this instance is available.
MDB don’t throw RemoteException. In general, they can throw exceptions but can’t return them back to the client in many cases, so a problem of “poison messages” appears (this problem may be solved, for example, by logging).
MDB support only REQUIRED and NOT_SUPPORTED transaction attributes (those, which have no notion of client). If something goes wrong, CMT allows message delivery to be rolled back.
MDB are single-threaded; however, concurrent processing is provided by using multiple instances of MDB, so one never knows the order in which messages are processed. This feature improves MDB scalability.
MDB can be pooled.

JMS

JMS provides standard API to MOM, it is not a messaging system itself but an abstraction of interfaces. JMS doesn’t have built-into security, so there is no way to propagate security with JMS messages, therefore some kind of message-layer or transport-layer security should be used. JMS transactions are specific: production and consumption of the message can’t be part of the same transaction.(MDB do not run in the same transaction as the producer) JMS transactional support lasts only till the queue’s or topic’s entry point. JMS messages may be encrypted using SSL. JMS may use HTTP tunneling but it is better suited for message exchange within a firewall and integration of applications within one department.
JMS messaging modes:
Pub/sub. Based on topics. Push-based model. Allows durable subscription(subscribers receive even those messages which were sent to them while they were not active) Message delivery is guaranteed only for durable subscribers.
P2P. Based on queues. Pull-based model (but may be turned into push-based). Message delivery is guaranteed for all subscribers.

JCA

JCA is the standard way to integrate JMS providers with J2EE application server using Resource Adapters. One needs JCA to put a message from non-Java producer into a JMS queue or topic. JCA is also used to access mainframe EIS. JCA solves infrastructure problems (resource pooling, transaction management, security, lifecycle management). JCA may work with non-relational databases. However, JCA introduces tight coupling, so it works best with small-scope integration problems and isn’t scalable.
JCA defines several aspects (contracts) which J2EE-compliant application must provide: lifecycle management, transactions, work management, security, connection, message inflow and transaction inflow contracts.
To connect to JCA EIS vendor provides pluggable resource adapter. JCA plugs this adapter into J2EE application server. (analogous to JDBC)

Examples of Legacy Connectivity and Integration:

WS – You have to integrate your application with another one across the firewall. Applications are written in different languages and run on different platforms. Reliability is not a crucial point. However, end-to-end security support would be beneficial. The main requirement is to make the architecture extensible enough to be able to add new services as fast as possible and to provide loose coupling and SOA.
JMS – You are implementing an intracorporate system of placing orders between departments. After an order is placed, one of departments handles it and processes in an asynchronous way.
JCA – You’ve got a mainframe application with no access to legacy code. On the other side you’ve got a large J2EE system which is not planned to be changed and extended to WS. Infrastructure support (transactions, security, etc.) is a crucial point and tight coupling is not a problem. So, you have to integrate those applications somehow.

Protocols and related technologies

2008-08-10T06:05:00.000-07:00

HTTP
HTTP doesn’t support RPC, which led to the development of SOAP.
Stateless, but state may be moved through URL rewriting or cookies. You can also use applets to maintain state.
HTTP is unreliable. Widely used for WS (SOAP is run over HTTP)

HTTPS
HTTPS adds encryption, identification of parties and session state.
Encryption used is only as strong as it is supported by the weakest side.
SSL handshake is a mutual verification of client and server.

IIOP
IIOP – protocol used by CORBA systems.
RMI/IIOP is commonly used for EJB.
Java applications can use IIOP in two ways: with RMI or with Java IDL.
IIOP and JRMP allow tunneling because any port is ok for them and they haven’t got any default port.

JRMP
JRMP is the default protocol for RMI.
To interoperate with other languages JNI may be used by JRMP, but they are supported only inside the system.
JRMP supports JAAS security and distributed garbage collection.

CORBA
CORBA is a technical standard.
CORBA is usually used for integration of existing software written in different languages.
ORB – object-oriented version of RPC.
Java IDL – the most direct way to use CORBA in Java applications; IDL – CORBA specification for exposing an interface.
RMI/IIOP also allows accessing CORBA.
In CORBA objects are usually passed by reference which introduces tight coupling. But since CORBA 2.3 OBV (objects by value) were introduced which lets one to introduce SOA with CORBA.
CORBA supports more languages than JNI.
CORBA can’t be run over HTTP.
CORBA may also provide asynchronicity, transactions and security.

RMI
Objects are passed by value (or???). Any parameters passed by value through RMI/IIOP are passed just as a sequence of bytes and, therefore, may be read only by Java clients. So, you need either CORBA or WS to support multiple languages.
Faster than JAX-RPC but less flexible.

Examples:
RMI/IIOP – You’ve got 2 systems each running in a EJB-container and you have to make them interoperate.
CORBA/IIOP with Java IDL– You’ve got a C++ application and a Java application. No other systems are planned for addition. You need support for transactions and security. Tight coupling is not considered a problem.
RMI/JRMP with JNI wrappers – You’ve got several Java applications but you need to incorporate small amount of services written in another language into them.
RMI/JRMP – You’ve got several distributed Java non-EJB applications which should work together. Distributed garbage collection would be a benefit.
HTTPS – You need transport-level security and session management.

Some points about EJB

2008-08-09T12:54:00.000-07:00

Choice between messaging and usage of RMI/IIOP

Messaging is preferable to mollify network overhead(when a lot of data is saved to database at the same time), to prioritize requests, provide better load balancing and run asynchronous processes. However, RMI/IIOP is better to perform transactional actions (an operation is a part of larger transaction), propagate security identity and is able to throw exceptions.

Choice between Stateful and Stateless session beans

Stateful session beans can cause input/output bottlenecks during passivation/activation. Callbacks (@PostActivate, PrePassivate etc.) are used, for example, for closing JDBC connections or releasing other resources bean has acquired. Before passivation all non-transient and non-serializable fields of a stateful session bean should be set to null. A bean involved in the transaction can't be passivated until the transaction ends. Stateless session bean can't by default be used by multiple clients concurrently(no support for multithreading). However, each next method call may be performed on another stateless bean because they are interchangeable.

GOF Design patterns in EJB

Flyweight: Bean pooling
Facade: Stateful beans as a facade for entity beans
Observer: MDB
Memento: bean passivation; 2PC
Proxy: Session bean acts as a proxy to Entity bean

EJB 3.0 and EJB 2.x interoperability

EJB 3.0 and 2.x are completely interoperable: EJB 3.0 can use EJB 2.x without any problems. EJB 2.x can’t use dependency injection when interoperating with EJB 3.0, instead they should use JNDI. They main problem one faces when migrating from EJB 2.x to EJB 3.0 is Entity beans migration (new entities are POJOs which support inheritance, etc., and may be run outside of EJB container, for example in Web container)

New, managed, removed and detached state of Entities

Removed beans are still associated with persistence context and have a persistent identity, they are just scheduled for removal.
If you remove a new entity, any cascaded removes are also performed

Tiers, layers, common architectures

2008-08-09T12:48:00.000-07:00

Tiers:

Client

Web

Business

Integration

Resource

Layers:

Application

Virtual platform (component API)

Application infrastructure (containers)

Enterprise services (operating system and virtualization)

Compute and storage

Networking infrastructure

Performance

Ways to improve: minimize the number of network calls, control the boundaries of certain parts of the system, perform resource pooling and caching, introduce optimistic locking, save session state on the server, use Session façade, tune pool size.

Ways to decrease: use pessimistic locking, use XML for EJB-EJB communication, activation/passivation, XML parsing

Scalability.

Can be vertical(increasing capacity) or horizontal(adding servers). Vertical is cheaper and doesn’t increase system’s complexity; however, it introduces single point of failure.

Ways to improve: adding more servers, choose a right level of transaction isolation, correct transaction management as a whole, better separation of concerns (tiering), using a connection pool, caching, asynchronous interaction

Ways to decrease: incorrect life cycle management, misapplication of stateless and stateful beans; ambiguous use of heavyweight components, client-server architecture

Reliability

Ways to improve: horizontal scalability, pessimistic locking, guaranteed message delivery, stateful session bean replication

Ways to decrease: optimistic locking, dirty reads, ignorance of concurrent threads (for instance, injecting EntityManager in a servlet), HTTP protocol

Availability

Ways to improve: introducing a cluster, hardware redundancies, asynchronous interaction, load balancing

Ways to decrease: network latency and breakage, hardware failover

Extensibility

Ways to improve: effective OO design, code reuse, refactoring, patterns; multitier architecture; Web Services; loose coupling, JCA, JMS

Ways to decrease: N+1 problem; tight coupling; access to legacy applications, databases, registries etc. without standard frameworks; ineffective Web tier design

Maintainability

Ways to improve: facades, separation of concerns, declarative instead of programmatic ways to manage security, transactions, persistence etc.; usage of container, connectors etc., Composite Entity,

Ways to decrease: code duplication, BMT, BMP, client-server architecture, direct SQL usage

Manageability

Ways to improve: single point of access/control, logging

Ways to decrease: additional tiers, many servers

Security

Ways to improve: HTTPS, firewalls, authentication, end-to-end security, encryption

Ways to decrease: point-to-point security, HTTP

1st message =)

2008-08-09T01:04:00.000-07:00

Hi everybody,
I'm preparing now for the Sun Certified Enterprise Architect exam which I'm planning to take in the end of August. Here I just wanna to put some of my notes on points which I consider be useful for reviewing. These notes do not pretend to be complete and don't cover the whole material on any of the topics. If you've got something to add, you are welcome. =)