Tuesday, 27 December 2011

SCEA/OCMJEA Part II assignment and Part III experience.

Prepartion for this exam started with different reason. I was mainly looking for refreshing my basics skills and learning few new techonologies so that I can cope up with the changing software market. Last year I wored Ayyapa mala (you need to workship Lord Ayyapa for 41 days with sanctity) and while following the rules and customs during the tenure, like wake up early in the morning and offer prayers before the sunrise. As my day starts early and I use to have plenty of time then I thought of making use of it and planned to appear for SCEA Part 1 which I was planning from many years but didn't get any time towards it. I started with Design patterns about the books and the material for SCEA part I, it is mentioned in my previous blog. By end of April I appeared and cleared part I but with I was not satisfied with the score and whole May I was busy with my office work and couldn't get any time for the part 2 exam.

Overall by completing part 1 itself I learned many new technologies in the stream of JEE 5. Before I was confident in few things like Servlet, JSP, EJB, JDBC and few things which were used lesser while working like Security, JSF. Apart from Security, JSF and many others things I have learned while I was preparing for part I.

Even though I cleared my SCEA/OCMJEA part 1 with just passing marks. I was not much confident of going for part 2. Timeline for submission of part 2 to avoid mandatory training sessions was 31st Aug and given this timeline added to it I don't have much experience in drawing UML diagrams. On 29th June I bought the voucher hoping that atleast in these 3 months I will think and implement what I have learned in part I in terms of building an end to end application. In my view its really very rare to get work experience of designing or thinking about the whole application right from the begining to end.

I downloaded the assignment and I felt its a new one which I haven't heard in any forum about this assignment, it's "Utility International". After reading the assignment thoroughly I felt it is associated with each and every JEE 5 technology starting from presentation, business and persistence tiers like JSP, EJB, JMS, WebServices.

I started designing the application with the things known to me very well and which are used in daily work. It was a simple class diagram by following the book of Mark Cade's. The flow of the application was like JSP->EJB->DAO and I started improving the design using J2EE patterns as well. The big mistake I have done in the initial design was adding a new class in domain model and also did some modifications to the relationships given in Domain model. By looking at the suggestions/comments in the javaranch forum about doing some modification in the domain model, it looked like it is not acceptable, until and unless you have good reason for the change.

There was an announcement from Oracle which contains good and bad news. Saying that assignment which is submitted before 31st Aug and if it is failed then there will be a second chance of submitting the assignment without going through mandatory course and also there is an extension of date saying 30th Sept. Assignments which are submitted before 31st Sept, if any one failed in assignment then mandatory course is required for resubmitting.

By this time it was second week of Aug and as the deadline was approaching and still my design was not in a good shape then I decided to submit it in Sept but with lot of risk. If I fail then there is no second chance for me. I thought if I missed then I will be stopped here itself. I was in a situation were I am left with only one arrow to hit the target without any backup.

When I read the deliverables section it was mentioned that whole assignments should be according to JEE 5. There was a slight confusion that my class diagram was mostly based on J2EE. There is no harm in designing it using J2EE but still couldn't digest the point of JEE and started redesigning the class diagram accordingly. This time the flow of the application goes like JSP page using JSF components, JSF components (Managed Beans) invokes stateless session methods, SLSB inturn uses Persistent objects. Most of the changes in the domain model were removed and used as is mentioned in assignment. One change required in my domain model with strong reason for changing it. I couldn't take any chances of doing any mistakes until I am totally convinced with my design.

There were 5 use cases which were mentioned. Each use case can be treated has a very big module if it is implemented in real time projects and it touches most of the corners of JEE 5 technology. For each and every use case sequence diagram is addressed. Every point in the use case if read properly it matches to any of non functional requirements. 

Component Diagram: It included with all the classes mentioned in the class diagram if we go according to the Mark Cades example, some people say it is kind of duplication of class diagram. But in this seperation in terms of tiers and how your application is interacted with the external systems and the framework used in. As DAO pattern was not used in my class diagram but when SuD interacts with the external system those details are to be gathered here and I used DAO to interact with the external system. This is also in similar lines of Mark Cades component diagram.

Deployment diagram: To my observation for OCMJEA most of them got failed in deployment diagram and this plays an important role in passing the exam. It was a two pages diagrams, Here as well my diagram is similar to Cades one but with few additions to the diagram and one more to make it fit to the application. These diagrams depict how the non functional requirements are met by the application.
Whenever I revisited the diagrams from end to end there was one or more points which I would have missed and it got addressed. I revisited my diagrams a lot number of times to make sure everything is addressed for meeting the functional and non functional requirements. For every visit there is one or other point which I missed, would have resulted in class/component diagram change. But revisiting the whole assignment will definately beneficial.

For drawing UML diagrams I used StarUML. Its really a very easy tool to use, I don't have much experience in drawing

Part III:

It is about Questions on the assignment you worked on. It was like how we met non functional requirements in our design and why a techonology is considered instead of others.

Atlast I received long awaited mail from Oracle of passing SCEA/OCMJEA 5 certification after 3 months of the assignment submission. Marks obtained 142/160, I received my Success Kit which contains a letter of Congratulations, Certificate and a card from Oracle.

Once again thanks to javaranch forum, Every information is available in the forum and most of the doubts were cleared. Special thanks to Dariusz Skrudlik and Anthony. Last but not the least my family supported a lot to achieve this certification and my son Meera Madhav who missed his dad while playing.

Saturday, 14 May 2011

SCEA Part I Exam CX-310-052 Notes

These are some points which are noted when I was preparing for the SCEA Part I CX-310-052 exam and hope that these are helpful for the people who are preparing for the exam. Below points are gathered from various books, topics and articles.

Experience in my exam:
There were good number of questions on patterns (both GOF and Core J2EE Patterns) and I couldn't see any question from UML in my exam.
Some questions were on Security and most of them are scenarios based which are quite bit lengthy.

Given a situation what would be the best in case, these kind of questions will definitely take some time to answer. 

For few Security based questions where all answers seems to be right 

Some how I successfully completed Oracle Certified Enterprise Architect Part I. This exam is of very vast syllabus. Before this exam, I know J2EE (few topics were less focused) and Java 1.4 but once I started preparing for this exam I got to know many things, most of the concepts atleast, not in detail but atleast each and every corner of the JEE 5 it has made me to go through.

I want to thank java ranch forum and javachamp.com for helping me in clearing Part I.

I started preparing for this exam by starting with GoF Design Patterns.

Books and references:
Head First Design Patterns

Core J2EE Design Patterns

Mark Cade's second edition
Mastering EJB3 fourth edition
SCEA study guide of Mikalia Zaikin 

Sun Certified Enterprise Architect for JavaEE Study Guide 2ndEd


n tier Architecture:
Validation of the common fields should be written in a common script so that browser downloads the script only once and it need not load the script for every page. Most of the pages which are having common fields can be validated using the same common script.

Browser validation logic will duplicate some server-side validation logic. The EJB and EIS tiers should validate data regardless of what client does.

Data that can be stored in Cookie is at most 4 KB.

With URL rewriting network will be consumed more as encoded session id and at the server again it is decoded for every request and response.

Server has to maintain the session of the user to keep track of the client it has to use a key to identify the client and get its session.

Preparing an application client for java web start deployment involves distributing its jar with a JNLP (java network launching protocol) file.

MIDlet clients are small applications programmed to the Mobile Information Device Profile(MIDP), a set of java API's which together with the CLDC(Connected Limited Device Configuration), provides a complete J2ME runtime environment for cellular phones.

Java client (client of rich client). When a list is requested by both the java client and browser based client. web based client has to load all the data including the presentation logic but in case of java client it loads only the data required for the client. java client(like swing application) consumes less bandwidth.

Java clients can be programmed to make fewer connections than a browser to a server.

LEB client is not always possible. First, only appliet and application clients may connect as EKB clients
(MIDlets cannot connect to the EJB tier because RMI is not a native component of MIDP).

JSF is a server side user interface component framework for java technology based web applications.

Services provided by the EJB container like security, connection pooling and transactions will be available by lightweight IOC (Inversion of Control, which is an event based programming model) containers like Spring, without the overhead and complexity of EJB.

Design Patterns from Head First series:

   Identify the aspects of your application that vary and seperate them from what stays the same.
   Program to an interface, not an implementation.
   Favor composition over inheritance.
   Strive for loosely coupled design between objects that interact.
   Classes should be open for extension but closed for modification.
   Depend upon abstractions. Do not depend upon concrete classes.
   Principle of Least Knowledge - talk only to your immediate friends.
   Don't call us, we will call you.
   A class should have only one reason to change.
   Cohension is a term to measure how closely a clas or a module supports a single purpose or responsibility. High cohesion when it is designed around a set of related functions and we say it has loow cohesion when it is desinged around a set of unrelated functions.
   Cohesion is a more general concept than the Single responsibility principle, but the two are closely related. Classes that adhere to the principle tend to have high cohesion and are more maintainable than classes that take on multiple responisibilities and have low cohesion.

    Pattern definition:
    Strategy Pattern defines a family of algorithm, encapsulate each one and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
    Observer Pattern defines one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and update automatically.
    Decorator attaches additional responsibiities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
    Factory method pattern defines an interface for creating an object, let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.
    Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.
    Singleton Pattern ensures a class has only one instance and provides a global point of access to it.
    Command pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.
    NoCommand object is an example of null object. A null objet is useful when you don't have a meaningful object to return, and yet you want to remove the responsibility of handling null from the client.
    Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
    Facade pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.
    Template Method defines skeleton of the algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine cetain steps of an algorithm without changing the algorithm's structure. Template method defines the steps of an algorithm and allows subclasses to provide the implementation for one or more steps.
    The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.   

    Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Core J2ee Patterns:   
DAO Pattern
    Use DAO to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.
    When the underlying storage is not subject to change from one implementation to another Factory for Data Access Objects strategy can be implemented to produce a number of DAOs needed by the application.
    When the underlying storage is subject to change from one implementation to another, Abstract Factory pattern for DAO strategy may be implemented using the Abstract Factory pattern. The Abstract Factory can in turn build on and use the Factory Method implementation.

Transfer Object Pattern
    Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.

Because the Transfer Object is passed by value to the client, all calls to the Transfer Object instance are local calls instead of remote method invocations.   

    A Transfer Object class may provide a constructor that accepts all the required attributes to create the Transfer Object. The constructor may accept all entity bean attribute values that the Transfer Object is designed to hold. Typically, the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods. If some protection is necessary, then the members could be defined as protected or private, and methods are provided to get the values. By offering no methods to set the values, a Transfer Object is protected from modification after its creation. If only a few members are allowed to be modified to facilitate updates, then methods to set the values can be provided.    
     Updatable Transfer Object
     Instead of providing fine-grained set methods for each attribute, which results in network overhead, the BusinessObject can expose a coarse-grained setData() method that accepts a Transfer Object as an argument. The Transfer Object passed to this method holds the updated values from the client. Since the Transfer Object has to be mutable, the Transfer Object class has to provide set methods for each attribute that can be modified by the client. The set methods for the Transfer Object can include field level validations and integrity checks as needed.
     Multiple Transfer Objects Strategy
     For instance, when the business object is implemented as a session bean, typically applying the Session Facade pattern, the bean may interact with numerous other business components to provide the service. The session bean produces its Transfer Object from different sources. Similarly, when the BusinessObject is implemented as a coarse-grained entity bean, typically applying the Composite Entity pattern, the entity bean will have complex relationships with a number of dependent objects. In both these cases, it is good practice to provide mechanisms to produce Transfer Objects that actually represent parts of the underlying coarse-grained components.
     Entity Inherits Transfer Object Strategy
     Transfer Object Factory strategy
Transfer Object Assembler
    ValueObject is created using the business data from various beans like entity bean, session bean and DAO, it fetches data from these business objects and creates a single Value Object (Transfer Object) and the built transfer object is used by the transfer object assembler.
Service Activator
    Provides Asynchronous Processing for any Enterprise Beans
In the EJB 2.0 specification, the message-driven bean is a stateless session bean. Using the Service Activator pattern, it is possible to provide asynchronous invocation on all types of enterprise beans, including stateless session beans, stateful session beans, and entity beans. As previously explained, since the Service Activator is implemented in its own right, without any limitations of the message-driven bean, the Service Activator can perform asynchronous invocations on any type of business service. Thus, this pattern provides a way to enable asynchronous processing for clients that either have no need to wait for the results or do not want to wait for processing to complete. The processing can be deferred and performed at a later time, enabling the client to complete the service in less time
Service Locator
        Use a Service Locator object to abstract all JNDI usage and to hide the complexities of initial context creation, EJB home object lookup, and EJB object re-creation. Multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility.

       JMS Queue Service Locator Strategy
        This strategy is applicable to point-to-point messaging requirements. The Service Locator for JMS components uses QueueConnectionFactory objects in the role of the ServiceFactory. The QueueConnectionFactory is looked up using its JNDI name. The QueueConnectionFactory can be cached by the ServiceLocator for future use. This avoids repeated JNDI calls to look it up when the client needs it again. The ServiceLocator may otherwise hand over the QueueConnectionFactory to the client. The Client can then use it to create a QueueConnection. A QueueConnection is necessary in order to obtain a QueueSession or to create a Message, a QueueSender (to send messages to the queue), or a QueueReceiver (to receive messages from a queue). The class diagram for the JMS Queue Service Locator strategy is shown in Figure 8.35. In this diagram, the Queue is a JMS Destination object registered as a JNDI-administered object representing the queue. The Queue object can be directly obtained from the context by looking it up using its JNDI name.
Session Facade
    Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
    Stateless Session Facade Strategy
    A business process that needs only one method call to complete the service is a nonconversational business process. Such processes are suitably implemented using a stateless session bean.

    Stateful Session Facade Strategy
    A business process that needs multiple method calls to complete the service is a conversational business process. The conversational state must be saved between each client method invocation. In this scenario, a stateful session bean may be a more suitable approach for implementing the Session Facade.

 Message beans cannot be accessed by web service clients.
 Web service client can invoke the business methods of a stateless session bean.
 A web service client accesses a stateless session bean through the bean's web service endpoint implementation class. Only business methods annotated as a @WebMethod may be invoked by a web service client.

 Tight or loose coupling of related beans: Tightly coupled beans depend on one another. For example, a completed sales order must email the customer a confirmation message upon completion of the order. If the SalesOrder stateful session bean, which contains the business logic of an ordering application, calls the CustomerContact  stateless session bean to email the order confirmation to the customer, these session beans would be described as tightly coupled. Tightly coupled beans are good candidates for local access. Because they fit together as a logical unit, they typically call each other often and would benefit from the increased performance that is possible with local access.

 The parameters of remote calls are more isolated than those of local calls. With remote calls, the client and bean operate on different copies of a parameter object. If the client changes the value of the object, the value of the copy in the bean does not change. This layer of isolation can help protect the bean if the client accidentally modifies the data.

In a local call, both the client and the bean can modify the same parameter object. In general, you should not rely on this side effect of local calls. Perhaps someday you will want to distribute your components, replacing the local calls with remote ones.

 . The client initiates the life cycle by obtaining a reference to a stateful session bean. The container performs any dependency injection and then invokes the method annotated with @PostConstruct, if any.

 The client initiates the life cycle by obtaining a reference to a stateless session bean.

 The EJB container usually creates a pool of message-driven bean instances.

 The business interface is a local interface unless it is annotated with the javax.ejb.Remote annotation; the javax.ejb.Local annotation is optional in this case.

 The bean class may implement more than one interface. If the bean class implements more than one interface, the bean class's business interfaces must be explicitly annotated either @Local or @Remote.

 # javax.annotation.PostConstruct
# javax.annotation.PreDestroy
# javax.ejb.PostActivate
# javax.ejb.PrePassivate

There is no Home interface in EJB3.

the bean provider can designate the business interface as a remote busines interfface or local business interface or both. Whereas the mthods on a remote business interface can throw arbitarray application exceptions they are not allowed to throw java.rmi.RemoteException,

Deployment descriptor can be annoted in the bean or deployment descriptor can be mentioned in the xml. If a transaction attribute is mentioned in the bean class and the deployment descriptor, value described in the DD will override the value mentioned in the bean.

If there is no deployment descriptor mentioned by the bean developer then container will generate its specific DD for the bean.

for the remote interface if nothing is declared has remote or local, by default container will treat it has local interface.

If the bean implementation has more than one interface to implement then every interface has to mention whether its remote or local and its mandatory.

Bean class if it implements more than one business then it has to be mention local or remote for every interface it implements.

local interface need not throw RemoteException

Java  Persistence API

To add new entity to the persistence context we need to call the Entity Manager's persist() method. The entity is now scehduled for synchronization with the database and will get written to disk when the transaction commits. This state in the entity's life cycle is called the managed state. It will end either persistence context ends or commits

detached state: when the transaction is committed or rolls back. the connection between persistence context and all managed entities and entity manager is removed, entities state is changed to detached state.

There are two options for client code that needs to use an EntityManager
container managed Entity Manager. container injects the Entity Manager when we used @PersistenceContext annotation and it can also be obtained from the SesionContext using its lookup()

application-managed Entity Manager, the app is responsible for creating an EntityManager instance itself using EntityManagerFactory.

Entity life cycle

new instance is created but not yet associated with persistence context. not yet synchronized in the database.

managed entity has persistent identity in the database and is currently associated with a persistence context.

detached, removed
Persistence Context
A persistence context is a set of managed entity instances that exist in a particular data store. The EntityManager interface defines the methods that are used to interact with the persistence context.

Container-Managed Entity Managers

EntityManager em;

Application-Managed Entity Managers

EntityManagerFactory emf;
EntityManager em = emf.createEntityManager();

Persisting Entity Instances
New entity instances become managed and persistent by invoking its persist method. This means the entity's data is stored to the database when the transaction associated with the persist operation is completed. If the entity is already managed, the persist operation is ignored. If persist is called on a removed entity instance, it becomes managed. If the entity is detached, persist will throw an IllegalArgumentException, or the transaction commit will fail.

Managing an Entity Instance's Lifecycle

You manage entity instances by invoking operations on the entity via an EntityManager instance. Entity instances are in one of four states: new, managed, detached, or removed.

New entity instances have no persistent identity and are not yet associated with a persistence context.

Managed entity instances have a persistent identity and are associated with a persistence context.

Detached entity instances have a persistent identify and are not currently associated with a persistence context.

Removed entity instances have a persistent identity, are associated with a persistent context, and are scheduled for removal from the data store.

Interface                                POINT TO POINT                          PUBLISH/SUBSCRIBE
ConnectionFactory                QueueConnectionFactory                  TopicConnctionFactory
Connection                            QueueConnection                             TopicConnection
Destination                             Queue                                              Topic
Session                                  QueueSession                                   TopicSession
MessageProducer                  QueueSender                                    TopicPublisher
MessageConsumer                QueueReceiver, QueueBrowser         TopicSubscriber

Message drive beans are single threaded. There is no need to synchronization code in the bean class. It is the container's responsibility to provide concurrent message consumption by pooling multiple mdb instances.

messages from a queue are delivered only to one consumer, the queue can have multiple messages processed concurrently by different servers in a cluster.

since messages from a topic can be consumed by more than one client, each mdb container that binds to a given topic will receive each msg.

poison msg is a msg that is continually retransmitted by a jms destination to the consumer because the consumer continuously fails to acknowledge the sonsumption of the msg.


Automatic Memory Management
Garbage Collection
Range checking on arrays and Strings
Compiler and Byte code verifier ensures only legitimate byte code is executed
Trusted applet run in local then in sandbox , unsigned applet still run in sandbox.

Deployment Descriptors for Declarative Security
  EJB uses ejb-jar.xml
  webservices jaxrpc-mapping-info.
  web application web.xml
Annotations enable a declarative style of programming, and so encompass both the declarative and programmatic security concepts.

a realm is a complete database of users and groups that identify valid users of a Web application.

the file, admin-realm, and certificate realms.

In the file realm, the server stores user credentials locally in a file named keyfile. File realm authenticates all the clients but https and certificate based clients are not authenticated.

certificate realm, the authentication service verifies an X.509 certificate.

The admin-realm is also a FileRealm and stores administrator user credentials locally in a file named admin-keyfile.
Security policy domain (also known as security domain or realm)

@DeclareRoles annotation (preferred) or the security-role-ref elements of the deployment descriptor

               This role includes the employees of the payroll
               department. The role is allowed to view and
               update the payroll entry for any employee.

                    This role should be assigned to the
                    employees of the payroll department.
                    Members of this role have access to
                    anyone's payroll record.
                    The role has been linked to the
                    payroll-department role.

This is accomplished by adding the <login-config> element to the runtime deployment descriptor, sun-ejb-jar.xml.

Method permissions in the deployment descriptor using the method-permission el

RunAs annotation @RunAs("admin")

  # Alternately, you can use the use-caller-identity element to indicate that you want to use the identity of the original caller, as shown in the code below:

  <use-caller-identity />

Securing Application Clients

Using Login Modules

An application client can use the Java Authentication and Authorization Service (JAAS) to create login modules for authentication. A JAAS-based application implements the javax.security.auth.callback.CallbackHandler interface so that it can interact with users to enter specific authentication data, such as user names or passwords, or to display error and warning messages.

Securing EIS Applications

Container-Managed Sign-On

In container-managed sign-on, an application component does not have to pass any sign-on security information to the getConnection() method. The security information is supplied by the container, as shown in the following example.

// Business method in an application component
Context initctx = new InitialContext();
// Perform JNDI lookup to obtain a connection factory
javax.resource.cci.ConnectionFactory cxf =
// Invoke factory to obtain a connection. The security
// information is not passed in the getConnection method
javax.resource.cci.Connection cx = cxf.getConnection();

Component-Managed Sign-On

In component-managed sign-on, an application component is responsible for passing the needed sign-on security information to the resource to the getConnection() method. For example, security information might be a user name and password, as shown here:

// Method in an application component
Context initctx = new InitialContext();
// Perform JNDI lookup to obtain a connection factory
javax.resource.cci.ConnectionFactory cxf =
// Get a new ConnectionSpec
com.myeis.ConnectionSpecImpl properties = //..
// Invoke factory to obtain a connection
javax.resource.cci.Connection cx =

  Specifying @DeclareRoles("employee") is equivalent to defining the following in the web.xml:


Nandhikanti Naresh Kumar.