Sunday, April 12, 2009

JMS-1

Q:

What is point-to-point messaging?
A: With point-to-point message passing the sending application/client establishes a named message queue in the JMS broker/server and sends messages to this queue. The receiving client registers with the broker to receive messages posted to this queue. There is a one-to-one relationship between the sending and receiving clients.

[ Received from Prasanna Inamanamelluri ]

TOP

Q:

Can two different JMS services talk to each other? For instance, if A and B are two different JMS providers, can Provider A send messages directly to Provider B? If not, then can a subscriber to Provider A act as a publisher to Provider B?
A: The answers are no to the first question and yes to the second. The JMS specification does not require that one JMS provider be able to send messages directly to another provider. However, the specification does require that a JMS client must be able to accept a message created by a different JMS provider, so a message received by a subscriber to Provider A can then be published to Provider B. One caveat is that the publisher to Provider B is not required to handle a JMSReplyTo header that refers to a destination that is specific to Provider A.

[ Received from Prasanna Inamanamelluri]

TOP

Q:

What is the advantage of persistent message delivery compared to nonpersistent delivery?
A: If the JMS server experiences a failure, for example, a power outage, any message that it is holding in primary storage potentially could be lost. With persistent storage, the JMS server logs every message to secondary storage. (The logging occurs on the front end, that is, as part of handling the send operation from the message producing client.) The logged message is removed from secondary storage only after it has been successfully delivered to all consuming clients .

[ Received from Prasanna Inamanamelluri]

TOP

Q:

Give an example of using the publish/subscribe model.
A: JMS can be used to broadcast shutdown messages to clients connected to the Weblogic server on a module wise basis. If an application has six modules, each module behaves like a subscriber to a named topic on the server.

[ Received from Prasanna Inamanamelluri]

TOP

Q:

Why doesn't the JMS API provide end-to-end synchronous message delivery and notification of delivery?
A: Some messaging systems provide synchronous delivery to destinations as a mechanism for implementing reliable applications. Some systems provide clients with various forms of delivery notification so that the clients can detect dropped or ignored messages. This is not the model defined by the JMS API.

JMS API messaging provides guaranteed delivery via the once-and-only-once delivery semantics of PERSISTENT messages. In addition, message consumers can ensure reliable processing of messages by using either CLIENT_ACKNOWLEDGE mode or transacted sessions. This achieves reliable delivery with minimum synchronization and is the enterprise messaging model most vendors and developers prefer.

The JMS API does not define a schema of systems messages (such as delivery notifications). If an application requires acknowledgment of message receipt, it can define an application-level acknowledgment message.


Received from Prasanna Inamanamelluri]

TOP

Q:

What are the various message types supported by JMS?
A: Stream Messages ? Group of Java Primitives
Map Messages ? Name Value Pairs. Name being a string& Value being a java primitive
Text Messages ? String messages (since being widely used a separate messaging Type has been supported)
Object Messages ? Group of serialize able java object
Bytes Message ? Stream of uninterrupted bytes

[ Received from Prasanna Inamanamelluri]

TOP

Q:

How is a java object message delivered to a non-java Client?
A: It is according to the specification that the message sent should be received in the same format. A non-java client cannot receive a message in the form of java object. The provider in between handles the conversion of the data type and the message is transferred to the other end.

[ Received from Prasanna Inamanamelluri]

TOP

Q:

What is MDB and What is the special feature of that?
A: MDB is Message driven bean, which very much resembles the Stateless session bean. The incoming and out going messages can be handled by the Message driven bean. The ability to communicate asynchronously is the special feature about the Message driven bean.

[ Received from Prasanna Inamanamelluri]

TOP

Q:

What are the types of messaging?
A: There are two kinds of Messaging.
Synchronous Messaging: Synchronous messaging involves a client that waits for the server to respond to a message.
Asynchronous Messaging: Asynchronous messaging involves a client that does not wait for a message from the server. An event is used to trigger a message from a server.

[ Received from Prasanna Inamanamelluri]

TOP

Q:

What are the core JMS-related objects required for each JMS-enabled application?
A: : Each JMS-enabled client must establish the following:
• A connection object provided by the JMS server (the message broker)
• Within a connection, one or more sessions, which provide a context for message sending and receiving
• Within a session, either a queue or topic object representing the destination (the message staging area) within the message broker
• Within a session, the appropriate sender or publisher or receiver or subscriber object (depending on whether the client is a message producer or consumer and uses a point-to-point or publish/subscribe strategy, respectively)
Within a session, a message object (to send or to receive)
.

[ Received from Prasanna Inamanamelluri]

JMS-0

Q:

What is JMS?
A: JMS is an acronym used for Java Messaging Service. It is Java's answer to creating software using asynchronous messaging. It is one of the official specifications of the J2EE technologies and is a key technology.

[ Received from Sandesh Sadhale]

TOP

Q:

How JMS is different from RPC?
A: In RPC the method invoker waits for the method to finish execution and return the control back to the invoker. Thus it is completely synchronous in nature. While in JMS the message sender just sends the message to the destination and continues it's own processing. The sender does not wait for the receiver to respond. This is asynchronous behavior.

[ Received from Sandesh Sadhale]

TOP

Q:

What are the advantages of JMS?
A: JMS is asynchronous in nature. Thus not all the pieces need to be up all the time for the application to function as a whole. Even if the receiver is down the MOM will store the messages on it's behalf and will send them once it comes back up. Thus at least a part of application can still function as there is no blocking.

[ Received from Sandesh Sadhale]

TOP

Q:

Are you aware of any major JMS products available in the market?
A: IBM's MQ Series is one of the most popular product used as Message Oriented Middleware. Some of the other products are SonicMQ, iBus etc.All the J2EE compliant application servers come built with thier own implementation of JMS.

[ Received from Sandesh Sadhale]

TOP

Q:

What are the different types of messages available in the JMS API?
A: Message, TextMessage, BytesMessage, StreamMessage, ObjectMessage, MapMessage are the different messages available in the JMS API.

TOP


Q:

What are the different messaging paradigms JMS supports?
A: Publish and Subscribe i.e. pub/suc and Point to Point i.e. p2p.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the difference between topic and queue?
A: A topic is typically used for one to many messaging i.e. it supports publish subscribe model of messaging. While queue is used for one-to-one messaging i.e. it supports Point to Point Messaging.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the role of JMS in enterprise solution development?
A: JMS is typically used in the following scenarios
1. Enterprise Application Integration: - Where a legacy application is integrated with a new application via messaging.
2. B2B or Business to Business: - Businesses can interact with each other via messaging because JMS allows organizations to cooperate without tightly coupling their business systems.
3. Geographically dispersed units: - JMS can ensure safe exchange of data amongst the geographically dispersed units of an organization.
4. One to many applications: - The applications that need to push data in packet to huge number of clients in a one-to-many fashion are good candidates for the use JMS. Typical such applications are Auction Sites, Stock Quote Services etc.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the use of Message object?
A: Message is a light weight message having only header and properties and no payload. Thus if theIf the receivers are to be notified abt an event, and no data needs to be exchanged then using Message can be very efficient.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the basic difference between Publish Subscribe model and P2P model?
A: Publish Subscribe model is typically used in one-to-many situation. It is unreliable but very fast. P2P model is used in one-to-one situation. It is highly reliable.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the use of BytesMessage?
A: BytesMessage contains an array of primitive bytes in it's payload. Thus it can be used for transfer of data between two applications in their native format which may not be compatible with other Message types. It is also useful where JMS is used purely as a transport between two systems and the message payload is opaque to the JMS client. Whenever you store any primitive type, it is converted into it's byte representation and then stored in the payload. There is no boundary line between the different data types stored. Thus you can even read a long as short. This would result in erroneous data and hence it is advisable that the payload be read in the same order and using the same type in which it was created by the sender.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the use of StreamMessage?
A: StreamMessage carries a stream of Java primitive types as it's payload. It contains some conveient methods for reading the data stored in the payload. However StreamMessage prevents reading a long value as short, something that is allwed in case of BytesMessage. This is so because the StreamMessage also writes the type information alonwgith the value of the primitive type and enforces a set of strict conversion rules which actually prevents reading of one primitive type as another.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the use of TextMessage?
A: TextMessage contains instance of java.lang.String as it's payload. Thus it is very useful for exchanging textual data. It can also be used for exchanging complex character data such as an XML document.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the use of ObjectMessage?
A: ObjectMessage contains a Serializable java object as it's payload. Thus it allows exchange of Java objects between applications. This in itself mandates that both the applications be Java applications. The consumer of the message must typecast the object received to it's appropriate type. Thus the consumer should before hand know the actual type of the object sent by the sender. Wrong type casting would result in ClassCastException. Moreover the class definition of the object set in the payload should be available on both the machine, the sender as well as the consumer. If the class definition is not available in the consumer machine, an attempt to type cast would result in ClassNotFoundException. Some of the MOMs might support dynamic loading of the desired class over the network, but the JMS specification does not mandate this behavior and would be a value added service if provided by your vendor. And relying on any such vendor specific functionality would hamper the portability of your application. Most of the time the class need to be put in the classpath of both, the sender and the consumer, manually by the developer.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the use of MapMessage?
A: A MapMessage carries name-value pair as it's payload. Thus it's payload is similar to the java.util.Properties object of Java. The values can be Java primitives or their wrappers.

[ Received from Sandesh Sadhale]

TOP

Q:

What is the difference between BytesMessage and StreamMessage??
A: BytesMessage stores the primitive data types by converting them to their byte representation. Thus the message is one contiguous stream of bytes. While the StreamMessage maintains a boundary between the different data types stored because it also stores the type information along with the value of the primitive being stored. BytesMessage allows data to be read using any type. Thus even if your payload contains a long value, you can invoke a method to read a short and it will return you something. It will not give you a semantically correct data but the call will succeed in reading the first two bytes of data. This is strictly prohibited in the StreamMessage. It maintains the type information of the data being stored and enforces strict conversion rules on the data being read.

[ Received from Sandesh Sadhale]

TOP

EJB-1

Q:

How EJB Invocation happens?

A: Step 1: Retrieve Home Object reference from Naming Service via JNDI.
step 2: Return Home Object reference to the client.
step 3: Create me a new EJB Object through Home Object interface.
step 4: Create EJB Object from the Ejb Object
step 5: Return EJB Object reference to the client.
step 6: Invoke business method using EJB Object reference.
step 7: Delegate request to Bean (Enterprise Bean).
[ Received from Ramana Bhavanasi]

Q:

Is it possible to share an HttpSession between a JSP and EJB? What happens when I change a value in the HttpSession from inside an EJB?

A: You can pass the HttpSession as parameter to an EJB method, only if all objects in session are serializable.This has to be consider as ?passed-by-value", that means that it?s read-only in the EJB. If anything is altered from inside the EJB, it won?t be reflected back to the HttpSession of the Servlet Container.The ?pass-by-reference? can be used between EJBs Remote Interfaces, as they are remote references. While it IS possible to pass an HttpSession as a parameter to an EJB object, it is considered to be ?bad practice ? in terms of object oriented design. This is because you are creating an unnecessary coupling between back-end objects (ejbs) and front-end objects (HttpSession). Create a higher-level of abstraction for your ejb?s api. Rather than passing the whole, fat, HttpSession (which carries with it a bunch of http semantics), create a class that acts as a value object (or structure) that holds all the data you need to pass back and forth between front-end/back-end. Consider the case where your ejb needs to support a non-http-based client. This higher level of abstraction will be flexible enough to support it.
[ Received from Nishit Kamdar]

Q:

The EJB container implements the EJBHome and EJBObject classes. For every request from a unique client, does the container create a separate instance of the generated EJBHome and EJBObject classes?

A: The EJB container maintains an instance pool. The container uses these instances for the EJB Home reference irrespective of the client request. while refering the EJB Object classes the container creates a separate instance for each client request. The instance pool maintainence is up to the implementation of the container. If the container provides one, it is available otherwise it is not mandatory for the provider to implement it. Having said that, yes most of the container providers implement the pooling functionality to increase the performance of the application server. The way it is implemented is again up to the implementer.
[ Received from Vishal Khasgiwala ]

Q:

Can the primary key in the entity bean be a Java primitive type such as int?

A:

The primary key can't be a primitive type--use the primitive wrapper classes, instead. For example, you can use java.lang.Integer as the primary key class, but not int (it has to be a class, not a primitive)

[ Received from Prasanna Inamanamelluri ]

Q:

Can you control when passivation occurs?

A:

The developer, according to the specification, cannot directly control when passivation occurs. Although for Stateful Session Beans, the container cannot passivate an instance that is inside a transaction. So using transactions can be a a strategy to control passivation.

The ejbPassivate() method is called during passivation, so the developer has control over what to do during this exercise and can implement the require optimized logic.

Some EJB containers, such as BEA WebLogic, provide the ability to tune the container to minimize passivation calls.

Taken from the WebLogic 6.0 DTD -"The passivation-strategy can be either "default" or "transaction". With the default setting the container will attempt to keep a working set of beans in the cache. With the "transaction" setting, the container will passivate the bean after every transaction (or method call for a non-transactional invocation).

[ Received from Prasanna Inamanamelluri ]

Q:

What is the advantage of using Entity bean for database operations, over directly using JDBC API to do database operations? When would I use one over the other?

A:

Entity Beans actually represents the data in a database. It is not that Entity Beans replaces JDBC API. There are two types of Entity Beans Container Managed and Bean Mananged. In Container Managed Entity Bean - Whenever the instance of the bean is created the container automatically retrieves the data from the DB/Persistance storage and assigns to the object variables in bean for user to manipulate or use them. For this the developer needs to map the fields in the database to the variables in deployment descriptor files (which varies for each vendor).

In the Bean Managed Entity Bean - The developer has to specifically make connection, retrive values, assign them to the objects in the ejbLoad() which will be called by the container when it instatiates a bean object. Similarly in the ejbStore() the container saves the object values back the the persistance storage. ejbLoad and ejbStore are callback methods and can be only invoked by the container. Apart from this, when you use Entity beans you dont need to worry about database transaction handling, database connection pooling etc. which are taken care by the ejb container. But in case of JDBC you have to explicitly do the above features. what suresh told is exactly perfect. ofcourse, this comes under the database transations, but i want to add this. the great thing about the entity beans of container managed, whenever the connection is failed during the transaction processing, the database consistancy is mantained automatically. the container writes the data stored at persistant storage of the entity beans to the database again to provide the database consistancy. where as in jdbc api, we, developers has to do manually.

[ Received from Prasanna Inamanamelluri ]
TOP

Q:

What is EJB QL?

A:

EJB QL is a Query Language provided for navigation across a network of enterprise beans and dependent objects defined by means of container managed persistence. EJB QL is introduced in the EJB 2.0 specification. The EJB QL query language defines finder methods for entity beans with container managed persistenceand is portable across containers and persistence managers. EJB QL is used for queries of two types of finder methods: Finder methods that are defined in the home interface of an entity bean and which return entity objects. Select methods, which are not exposed to the client, but which are used by the Bean Provider to select persistent values that are maintained by the Persistence Manager or to select entity objects that are related to the entity bean on which the query is defined.

[ Received from Prasanna Inamanamelluri ]

Q:

Brief description about local interfaces?

A:

EEJB was originally designed around remote invocation using the Java Remote Method Invocation (RMI) mechanism, and later extended to support to standard CORBA transport for these calls using RMI/IIOP. This design allowed for maximum flexibility in developing applications without consideration for the deployment scenario, and was a strong feature in support of a goal of component reuse in J2EE.

Many developers are using EJBs locally -- that is, some or all of their EJB calls are between beans in a single container.

With this feedback in mind, the EJB 2.0 expert group has created a local interface mechanism. The local interface may be defined for a bean during development, to allow streamlined calls to the bean if a caller is in the same container. This does not involve the overhead involved with RMI like marshalling etc. This facility will thus improve the performance of applications in which co-location is planned.

Local interfaces also provide the foundation for container-managed relationships among entity beans with container-managed persistence.

[ Received from Prasanna Inamanamelluri ]

Q:

What are the special design care that must be taken when you work with local interfaces?

A:

EIt is important to understand that the calling semantics of local interfaces are different from those of remote interfaces. For example, remote interfaces pass parameters using call-by-value semantics, while local interfaces use call-by-reference.

This means that in order to use local interfaces safely, application developers need to carefully consider potential deployment scenarios up front, then decide which interfaces can be local and which remote, and finally, develop the application code with these choices in mind.

While EJB 2.0 local interfaces are extremely useful in some situations, the long-term costs of these choices, especially when changing requirements and component reuse are taken into account, need to be factored into the design decision.

[ Received from Prasanna Inamanamelluri ]

Q:

What happens if remove( ) is never invoked on a session bean?

A:

In case of a stateless session bean it may not matter if we call or not as in both cases nothing is done. The number of beans in cache is managed by the container.

In case of stateful session bean, the bean may be kept in cache till either the session times out, in which case the bean is removed or when there is a requirement for memory in which case the data is cached and the bean is sent to free pool.

[ Received from Prasanna Inamanamelluri ]

Q:

What is the difference between Message Driven Beans and Stateless Session beans?

A:

In several ways, the dynamic creation and allocation of message-driven bean instances mimics the behavior of stateless session EJB instances, which exist only for the duration of a particular method call. However, message-driven beans are different from stateless session EJBs (and other types of EJBs) in several significant ways:

Message-driven beans process multiple JMS messages asynchronously, rather than processing a serialized sequence of method calls.

Message-driven beans have no home or remote interface, and therefore cannot be directly accessed by internal or external clients. Clients interact with message-driven beans only indirectly, by sending a message to a JMS Queue or Topic.

Note: Only the container directly interacts with a message-driven bean by creating bean instances and passing JMS messages to those instances as necessary.

The Container maintains the entire lifecycle of a message-driven bean; instances cannot be created or removed as a result of client requests or other API calls.

[ Received from Prasanna Inamanamelluri ]

Q:

How can I call one EJB from inside of another EJB?

A:

EJBs can be clients of other EJBs. It just works. Use JNDI to locate the Home Interface of the other bean, then acquire an instance reference, and so forth.

[ Received from Prasanna Inamanamelluri ]

Q:

What is an EJB Context?

A:

EJBContext is an interface that is implemented by the container, and it is also a part of the bean-container contract. Entity beans use a subclass of EJBContext called EntityContext. Session beans use a subclass called SessionContext. These EJBContext objects provide the bean class with information about its container, the client using the bean and the bean itself. They also provide other functions. See the API docs and the spec for more details.

[ Received from Prasanna Inamanamelluri ]

Q:

The EJB container implements the EJBHome and EJBObject classes. For every request from a unique client, does the container create a separate instance of the generated EJBHome and EJBObject classes?

A:

The EJB container maintains an instance pool. The container uses these instances for the EJB Home reference irrespective of the client request. While refering the EJB Object classes the container creates a separate instance for each client request. The instance pool maintainence is up to the implementation of the container. If the container provides one, it is available otherwise it is not mandatory for the provider to implement it. Having said that, yes most of the container providers implement the pooling functionality to increase the performance of the application server. The way it is implemented is again up to the implementer.

[ Received from Vishal Khasgiwala ]

EJB-0

Q:

What are the different kinds of enterprise beans?

A: Different kind of enterrise beans are Stateless session bean, Stateful session bean, Entity bean, Message-driven bean...........


Q:

What is Session Bean?

A: A session bean is a non-persistent object that implements some business logic running on the server. One way to think of a session object...........


Q:

What is Entity Bean?

A: The entity bean is used to represent data in the database. It provides an object-oriented interface to ...........


Q:

What are the methods of Entity Bean?

A: An entity bean consists of 4 groups of methods, create methods...........


Q:

What is the difference between Container-Managed Persistent (CMP) bean and Bean-Managed Persistent(BMP) ?

A: Container-managed persistence (CMP) and bean-managed persistence (BMP). With CMP, the container manages the persistence of the entity bean............


Q:

What are the callback methods in Entity beans?

A: Callback methods allows the container to notify the bean of events in
its life cycle. The callback methods are defined in the javax.ejb.EntityBean interface............


Q:

What is software architecture of EJB?

A: Session and Entity EJBs consist of 4 and 5 parts respectively, a remote interface...........


Q:

Can Entity Beans have no create() methods?

A: Yes. In some cases the data is inserted NOT using Java application,...........


Q:

What is bean managed transaction?

A: If a developer doesn't want a Container to manage transactions, it's possible to implement all database operations manually...........


Q:

What are transaction attributes?

A: The transaction attribute specifies how the Container must manage transactions for a method when a client invokes the method via the enterprise bean’s home or...........


Q:

What are transaction isolation levels in EJB?

A: Transaction_read_uncommitted , Transaction_read_committed , Transaction_repeatable_read...........


Servlets-0

Q:

Explain the life cycle methods of a Servlet.

A: The javax.servlet.Servlet interface defines the three methods known as life-cycle method.
public void init(ServletConfig config) throws ServletException
public void service( ServletRequest req, ServletResponse res) throws ServletException, IOException
public void destroy()

First the servlet is constructed, then initialized wih the init() method.
Any request from client are handled initially by the service() method before delegating to the doXxx() methods in the case of HttpServlet.

The servlet is removed from service, destroyed with the destroy() methid, then garbaged collected and finalized.


Q:

What is the difference between the getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface and javax.servlet.ServletContext interface?

A: The getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface accepts parameter the path to the resource to be included or forwarded to, which can be relative to the request of the calling servlet. If the path begins with a "/" it is interpreted as relative to the current context root.

The getRequestDispatcher(String path) method of javax.servlet.ServletContext interface cannot accepts relative paths. All path must sart with a "/" and are interpreted as relative to curent context root.


Q:

Explain the directory structure of a web application.

A: The directory structure of a web application consists of two parts.
A private directory called WEB-INF
A public resource directory which contains public resource folder.

WEB-INF folder consists of
1. web.xml
2. classes directory
3. lib directory


Q:

What are the common mechanisms used for session tracking?

A: Cookies
SSL sessions
URL- rewriting


Q:

Explain ServletContext.

A: ServletContext interface is a window for a servlet to view it's environment. A servlet can use this interface to get information such as initialization parameters for the web applicationor servlet container's version. Every web application has one and only one ServletContext and is accessible to all active resource of that application.


Q:

What is preinitialization of a servlet?

A: A container doesnot initialize the servlets ass soon as it starts up, it initializes a servlet when it receives a request for that servlet first time. This is called lazy loading. The servlet specification defines the element, which can be specified in the deployment descriptor to make the servlet container load and initialize the servlet as soon as it starts up. The process of loading a servlet before any request comes in is called preloading or preinitializing a servlet.
[ Received from Amit Bhoir ]

Q:

What is the difference between Difference between doGet() and doPost()?

A: A doGet() method is limited with 2k of data to be sent, and doPost() method doesn't have this limitation. A request string for doGet() looks like the following:
http://www.allapplabs.com/svt1?p1=v1&p2=v2&...&pN=vN
doPost() method call doesn't need a long text tail after a servlet name in a request. All parameters are stored in a request itself, not in a request string, and it's impossible to guess the data transmitted to a servlet only looking at a request string.
[ Received from Amit Bhoir ]

Q:

What is the difference between HttpServlet and GenericServlet?

A: A GenericServlet has a service() method aimed to handle requests. HttpServlet extends GenericServlet and adds support for doGet(), doPost(), doHead() methods (HTTP 1.0) plus doPut(), doOptions(), doDelete(), doTrace() methods (HTTP 1.1).
Both these classes are abstract.
[ Received from Amit Bhoir ]

Q:

What is the difference between ServletContext and ServletConfig?

A: ServletContext: Defines a set of methods that a servlet uses to communicate with its servlet container, for example, to get the MIME type of a file, dispatch requests, or write to a log file.The ServletContext object is contained within the ServletConfig object, which the Web server provides the servlet when the servlet is initialized

ServletConfig: The object created after a servlet is instantiated and its default constructor is read. It is created to pass initialization information to the servlet.
[ Received from Sivagopal Balivada ]