A top software consulting is looking for Java developers. There are multiple open positions like Java Developers, Senior Java Developers, Technical Leads and Architects. Candidates who have strong knowledge in Java and in one or more of the following skills can apply:
Struts
Spring
Hibernate
Web services
JSP
EJB
Application servers like Weblogic or Websphere or JBoss.
Databases like Oracle or DB2.
Design tools like Rational Software Architect or Enterprise Architect.
Good knowledge in design patterns.
Version control systems like Clearcase or Subversion.
Company Information
The company is one of the top 4 software consulting companies in US with over 56,000 employees and offices in 87 cities. The company provides very good pay package and benefits. For those who are on H1, the company will transfer H1.
Note: I am an employee of the company and your profile will be submitted as an internal referral.
A point-to-point (PTP) product or application is built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire. Point-to-Point Messaging has the following characteristics:
Each Message has only one consumer.
The receiver can fetch the message whether or not it was running when the client sent the message.
The receiver acknowledges the successful processing of a message.
In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers. Pub/sub messaging has the following characteristics:
Each message may have multiple consumers.
Publishers and subscribers have a timing dependency. A client that subscribes to a topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.
Synchronous Consumption :A subscriber or a receiver explicitly fetches the message from the destination by calling the receive method. The receive method can block until a message arrives or can time out if a message does not arrive within a specified time limit.
Asynchronous Consumption : A client can register a message listener with a consumer. A message listener is similar to an event listener. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener's onMessage method, which acts on the contents of the message.
A connection factory is the object a client uses to create a connection with a provider. A connection factory encapsulates a set of connection configuration parameters that has been defined by an administrator.Each connection factory is an instance of either the QueueConnectionFactory or the TopicConnectionFactory interface.
A destination is the object a client uses to specify the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called queues and in the pub/sub messaging domain, destinations are called topics.
A message listener is an object that acts as an asynchronous event handler for messages. This object implements the MessageListener interface, which contains one method, onMessage. In the onMessage method, you define the actions to be taken when a message arrives.
Message selector filters the messages received by the consumer based on a criteria. Message selectors assign the work of filtering messages to the JMS provider rather than to the application. A message selector is a String that contains an expression. The syntax of the expression is based on a subset of the SQL92 conditional expression syntax. The message consumer then receives only messages whose headers and properties match the selector.
A JMS message header contains a number of predefined fields that contain values that both clients and providers use to identify and to route messages.Each header field has associated setter and getter methods, which are documented in the description of the Message interface.
A message is a package of business data that is sent from one application to another over the network. The message should be self-describing in that it should contain all the necessary context to allow the recipients to carry out their work independently.
TextMessage : A java.lang.String object (for example, the contents of an Extensible Markup Language file).
MapMessage : A set of name/value pairs, with names as String objects and values as primitive types in the Java programming language. The entries can be accessed sequentially by enumerator or randomly by name. The order of the entries is undefined.
BytesMessage : A stream of uninterpreted bytes. This message type is for literally encoding a body to match an existing message format.
StreamMessage: A stream of primitive values in the Java programming language, filled and read sequentially.
ObjectMessage: A Serializable object in the Java programming language.
A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. If the message driven bean pool contains more than one instance then messages can be processed concurrently and thus it is possible that a later message is processed sooner than an earlier one. A JMS queue only guarantees that each message is processed only once.
Java applications that use JMS are called JMS clients, and the messaging system that handles routing and delivery of messages is called the JMS provider. A JMS client that sends a message is called a producer, while a JMS client that receives a message is called a consumer. A single JMS client can be both a producer and a consumer.
Message-driven beans (MDBs) are stateless, server-side, transaction-aware components for processing asynchronous JMS messages. MDBs were introduced as part of EJB 2 specification. Message-driven beans process messages delivered via the Java Message Service.
A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. It acts as a JMS message listener, which is similar to an event listener except that it receives messages instead of events. The messages may be sent by any J2EE component--an application client, another enterprise bean, or a Web component or by a JMS application or system that does not use J2EE technology.
MDB's are only for internal processing. You cannot look up a MDB from client. If you want to access MDB you rather send a message to the Queue. Hence MDB's doesnt have a JNDI name. And for the same reason they dont have component interfaces.
The most visible difference between message-driven beans and session and entity beans is that clients do not access message-driven beans through interfaces. Unlike a session or entity bean, a message-driven bean has only a bean class.
In several respects, a message-driven bean resembles a stateless session bean.
A message-driven bean's instances retain no data or conversational state for a specific client.
All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently.
A single message-driven bean can process messages from multiple clients.
A message basically has two parts : a header and payload. The header is comprised of special fields that are used to identify the message, declare attributes of the message, and provide information for routing. Payload is the type of application data the message contains.
JMS delivery mode are of two types Non-Persistent and Persistent. Non-Persistent messages do not need to be stored in persistent storage in case of client failure. A JMS provider must deliver this kind of message at-most-once, i.e., the message can be lost, but can only be delivered once. Persistent messages are stored in persistent storage to be delivered at a later date if a client is unavailable. A JMS provider must deliver this kind of message once-and-only once, i.e., it cannot be lost and cannot be delivered more than once.
JMS Interview Questions & Answers