Configuring JMS Using JNDI

A program written against the JMS API can work with any vendor's implementation of JMS, as
long as it complies with the JMS specification. This is possible when the JMS client program uses

JNDI (the Java Naming and Directory Interface) to look up the initial "Connection Factory" object. Once this object has been looked up from the directory, it is used to create the "Connection" object, then the "Session" object, and so on until all the necessary objects are created. Since all these objects implement the standard JMS interfaces, any program that uses only the standard interfaces can interoperate with any compliant JMS provider. Plus, since the connection factory is stored in JNDI by the provider itself, it provides a place for the provider to put its own configuration information, such as the location of the server, or any special options it may implement.
Destination objects – queues and topics – can also be stored in JNDI. This gives each provider a way to associate special configuration parameters with each destination that may not be a part of the standard JMS interface.

JNDI is also a standard Java interface. Therefore, a client written to this standard API can look up information from any type of directory that implements the standard Java interfaces.

WebLogic Server uses JMS and JNDI when it interfaces with JMS inside the WebLogic Messaging Bridge, or when receiving messages for a message-driven bean. Stand-alone JMS clients,session beans, and servlets can also use JNDI to get access to a JMS provider.

Since WebLogic Server uses JNDI to look up the connection factory and destination objects, it can be configured to work with any JMS provider that properly implements the JMS and JNDI specifications.

In order for WebLogic Server to look up the JMS connection factory from JNDI, four pieces of information are needed. These are described below, and examples are provided later in this document:

Initial context factory. This is the name of the JNDI class that will be created to perform the lookup. This class may be part of the JDK, it may be provided by Sun Microsystems, or it may be provided by the JMS vendor itself.

Provider URL. This URL is used to tell the initial context factory where to find the directory information. It may refer to a server using a protocol like LDAP, or it may refer to a file in the filesystem, or something else.Connection factory JNDI name. This is the name of the connection factory object that is stored in JNDI. Each JMS provider creates its own tool to create this object and store it in JNDI. Once it is stored there, any JMS client program (including WebLogic Server) can look up the object.

Destination JNDI name. This is the object that represents a JMS destination – a queue or a topic – as stored in JNDI. Like the connection factory, each JMS provider will provide its own tool to create the object and place it in JNDI.

When setting up WebLogic Server to access a foreign JMS provider, these four parameters must be specified. The remaining topics in this section of this document describe how to use various JNDI providers. After that, section 3 describes the various JMS providers. You will need information from both sections to set up a particular interaction between JMS and WebLogic Server.

In this section, there is information about a few basic types of JNDI providers. General-purpose JNDI providers. The filesystem and LDAP providers are examples of general-purpose JNDI providers. They may be used to store various types of Java objects on behalf of many different types of servers. Normally, once an object is stored in a general-purpose JNDI provider, it remains there in persistent form and may be looked up at a later time after a server restart. MQSeries and SonicMQ are examples of JMS providers that rely on a general-purpose JNDI provider in order to provide interoperability with WebLogic Server.

Vendor-specific JNDI providers. Some JMS providers, such as FioranoMQ and IBus MessageServer, provide a JNDI interface of their own. JMS connection factory and destination objects may be looked up using this provider, usually without any additional configuration
required on the client or on the server. However, these providers only allow JNDI access to their own objects, and cannot be used to store additional information.

WebLogic JNDI. A JNDI provider is built in to WebLogic Server. It combines some aspects of a general-purpose JNDI provider with those of a vendor-specific provider. Like a generalpurpose JNDI provider, it can be used to store all kinds of objects, and users can use it to store their own objects as well. And like a vendor-specific provider, it is built in to WebLogic  Server and requires no additional configuration. JNDI objects that are created by the server itself, such as WebLogic Server JMS connection factory and destination objects, are automatically re-created when the server starts up. However, other objects that users store in JNDI are not automatically re-created, and must be inserted into JNDI every time the server starts up using a mechanism such as a WebLogic "startup class".

New Features in WebLogic Server 7.0

WebLogic Messaging Bridge

The WebLogic Messaging Bridge is a part of WebLogic Server that forwards messages from a "source" destination to a "target" destination. Out-of-the-box adapters are provided so that thesource and/or target may be a JMS destination. Either end can be a JMS topic or queue, and could be a server running WebLogic Server 5.1 or higher, or a foreign JMS provider. The WebLogic Messaging Bridge also provides interoperability between different versions of WebLogic Server.

Container-Managed Transactions for Message-Driven Beans

A message-driven bean (MDB) is a special type of Enterprise Java Bean (EJB) that pulls messages from a JMS queue or topic. The EJB container (WebLogic Server) is responsible for connecting to the JMS provider, receiving messages, and passing them to the MDB in the proper transaction context. This allows asynchronous events to be processed by a J2EE-based application, which was not possible in a standard way before MDBs..

WebLogic Server has supported MDBs since WebLogic Server 6.0. Version 6.0 SP1 of the server added support for foreign JMS providers. However, container-managed transactions could only be used with WebLogic JMS, so a foreign JMS provider could not participate in the WebLogic transaction.

Why Use a Foreign JMS Provider?

Customers sometimes need to use a different JMS provider from WebLogic JMS. Some of the reasons for doing this are:

Legacy system access - It may be necessary to use a foreign JMS provider because only that software provides access to a particular legacy system, because only that software connects to a platform where WebLogic Server is not available.

Message forwarding - Some customers may need to forward messages between a foreign JMS provider and WebLogic JMS, or even between two foreign JMS providers. In WebLogic Server 6.1 SP3 and 7.0, this can be accomplished without programming by using the Web-Logic Messaging Bridge. In addition, this document describes some ways to do this without using the bridge. Some customers may want to use two-phase commit when they do this in order to eliminate the possibility of losing or duplicating a message.

Driving message-driven beans - Some customers, especially those who need to access messages from legacy systems, may need to use a foreign JMS provider to supply messages to a message-driven bean.

HCL C Programmer Interview Question

1. Which of the following about the following two declaration is true
i ) int *F()
ii) int (*F)()
Choice :
a) Both are identical
b) The first is a correct declaration and the second is wrong
c) The first declaraion is a function returning a pointer to an
integer and the second is a pointer to function returning int
d) Both are different ways of declarin pointer to a function
2. What are the values printed by the following program?
#define dprint(expr) printf(#expr "=%d\n",expr)
main()
{
int x=7;
int y=3;
dprintf(x/y);
}
Choice:
a) #2 = 2 b) expr=2 c) x/y=2 d) none

3. What is th output of the following program?
int x= 0x65;
main()
{
char x;
printf("%d\n",x)
}
a) compilation error b) 'A' c) 65 d) unidentified
4. What is the output of the following program
main()
{
int a=10;
int b=6;
if(a=3)
b++;
printf("%d %d\n",a,b++);
}
a) 10,6 b)10,7 c) 3,6 d) 3,7 e) none

5. What can be said of the following program?
main()
{
enum Months {JAN =1,FEB,MAR,APR};
Months X = JAN;
if(X==1)
{
printf("Jan is the first month");
}
}
a) Does not print anything
b) Prints : Jan is the first month
c) Generates compilation error
d) Results in runtime error

6. What is the output of the following program?
main()
{
int l=6;
switch(l)
{ default : l+=2;
case 4: l=4;
case 5: l++;
break;
}
printf("%d",l);
}
a)8 b)6 c)5 d)4 e)none

7. What is the output of the following program?
main()
{
int x=20;
int y=10;
swap(x,y);
printf("%d %d",y,x+2);
}
swap(int x,int y)
{
int temp;
temp =x;
x=y;
y=temp;
}
a)10,20 b) 20,12 c) 22,10 d)10,22 e)none

8. What is the size of the following union. Assume that the size of
int =2, size of float =4 and size of
char =1.
Union Tag{
int a;
flaot b;
char c;
};
a)2 b)4 c)1 d) 7

AJAX = Asynchronous JavaScript and XML

AJAX is not a new programming language, but a technique for creating
better, faster, and more interactive web applications.

With AJAX, your JavaScript can communicate directly with the server,
using the JavaScript XMLHttpRequest object. With this object, your
JavaScript can trade data with a web server, without reloading the
page.

AJAX uses asynchronous data transfer (HTTP requests) between the
browser and the web server, allowing web pages to request small bits
of information from the server instead of whole pages.

The AJAX technique makes Internet applications smaller, faster and
more user-friendly.