FAQ's Programs

Frequently Asked Programs in Interviews


Web Services Interview Questions:


1. What is a Web service?
              A Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system.
Web services are self-contained, modular applications that can be described, published, located, and invoked over a network
               XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.
               A Web service may also have two additional (and desirable) properties:
i)  a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL).
ii)  if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration.

2. What is new about Web services?
         People have been using Remote Procedure Calls (RPC) for some time now, and they long ago discovered how to send such calls over HTTP.
So, what is really new about Web services? The answer is XML.
         XML lies at the core of Web services, and provides a common language for describing Remote Procedure Calls, Web services, and Web service directories.
        Prior to XML, one could share data among different applications, but XML makes this so much easier to do. In the same vein, one can share services and code without Web services, but XML makes it easier to do these as well.
        By standardizing on XML, different applications can more easily talk to one another, and this makes software a whole lot more interesting.

3. I keep reading about Web services, but I have never actually seen one. Can you show me a real Web service in action?
                     If you want a more intuitive feel for Web services, try out the IBM Web Services Browser, available on the IBM Alphaworks site. The browser provides a series of Web services demonstrations. Behind the scenes, it ties together SOAP, WSDL, and UDDI to provide a simple plug-and-play interface for finding and invoking Web services. For example, you can find a stock-quote service, a traffic-report service, and a weather service. Each service is independent, and you can stack services like building blocks. You can, therefore, create a single page that displays multiple services--where the end result looks like a stripped-down version of my.yahoo or my.excite.




4. What is the Web service protocol stack?
        The Web service protocol stack is an evolving set of protocols used to define, discover, and implement Web services. The core protocol stack consists of four layers:
Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).
XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.
Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.
Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.
               Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole zoo of newer, evolving protocols. These include WSFL (Web Services Flow Language), SOAP-DSIG (SOAP Security Extensions: Digital Signature), and USML (UDDI Search Markup Language). For an overview of these protocols, check out Pavel Kulchenko's article, Web Services Acronyms, Demystified, on XML.com.
              Fortunately, you do not need to understand the full protocol stack to get started with Web services. Assuming you already know the basics of HTTP, it is best to start at the XML Messaging layer and work your way up.
5. What is XML-RPC?
XML-RPC is a protocol that uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML and sent via HTTP POST; XML responses are embedded in the body of the HTTP response.
More succinctly, XML-RPC = HTTP + XML + Remote Procedure Calls.
Because XML-RPC is platform independent, diverse applications can communicate with one another. For example, a Java client can speak XML-RPC to a Perl server.
To get a quick sense of XML-RPC, here is a sample XML-RPC request to a weather service (with the HTTP Headers omitted):
<?xml version="1.0" encoding="ISO-8859-1"?>
<methodCall>
<methodName>weather.getWeather</methodName>
<params>
<param><value>10016</value></param>
</params>
</methodCall>
The request consists of a simple element, which specifies the method name (getWeather) and any method parameters (zip code).



Here is a sample XML-RPC response from the weather service:

<?xml version="1.0" encoding="ISO-8859-1"?>
<methodResponse>
<params>
<param>
<value><int>65</int></value>
</param>
</params>
</methodResponse>
The response consists of a single element, which specifies the return value (the current temperature). In this case, the return value is specified as an integer.
In many ways, XML-RPC is much simpler than SOAP, and therefore represents the easiest way to get started with Web services.
The official XML-RPC specification is available at XML-RPC.com. Dozens of XML-RPC implementations are available in Perl, Python, Java, and Ruby. See the XML-RPC home page for a complete list of implementations.
6. What is SOAP?
                SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.

To get a quick sense of SOAP, here is a sample SOAP request to a weather service (with the HTTP Headers omitted):

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getWeather
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle=" http://www.w3.org/2001/09/soap-encoding
<zipcode xsi:type="xsd:string">10016</zipcode>
</ns1:getWeather>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you can see, the request is slightly more complicated than XML-RPC and makes use of both XML namespaces and XML Schemas. Much like XML-RPC, however, the body of the request specifies both a method name (getWeather), and a list of parameters (zipcode).

Here is a sample SOAP response from the weather service:

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getWeatherResponse
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
<return xsi:type="xsd:int">65</return>
</ns1:getWeatherResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The response indicates a single integer return value (the current temperature).
The World Wide Web Consortium (W3C) is in the process of creating a SOAP standard. The latest working draft is designated as SOAP 1.2, and the specification is now broken into two parts. Part 1 describes the SOAP messaging framework and envelope specification. Part 2 describes the SOAP encoding rules, the SOAP-RPC convention, and HTTP binding details.
7. What is WSDL?
The Web Services Description Language (WSDL) currently represents the service description layer within the Web service protocol stack.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:

Information on all publicly available functions.
Data type information for all XML messages.
Binding information about the specific transport protocol to be used.
Address information for locating the specified service.

WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.

Below is a sample WSDL file. This file describes the public interface for the weather service used in the SOAP example above. Obviously, there are many details to understanding the example. For now, just consider two points.
First, the <message> elements specify the individual XML messages that are transferred between computers. In this case, we have a getWeatherRequest and a getWeatherResponse. Second, the element specifies that the service is available via SOAP and is available at a specific URL.




<?xml version="1.0" encoding="UTF-8"?>
<definitions name="WeatherService"
targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="getWeatherRequest">
<part name="zipcode" type="xsd:string"/>
</message>
<message name="getWeatherResponse">
<part name="temperature" type="xsd:int"/>
</message>

<portType name="Weather_PortType">
<operation name="getWeather">
<input message="tns:getWeatherRequest"/>
<output message="tns:getWeatherResponse"/>
</operation>
</portType>

<binding name="Weather_Binding" type="tns:Weather_PortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getWeather">
<soap:operation soapAction=""/>
<input>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice"
use="encoded"/>
</input>
<output>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice"
use="encoded"/>
</output>
</operation>
</binding>

<service name="Weather_Service">
<documentation>WSDL File for Weather Service</documentation>
<port binding="tns:Weather_Binding" name="Weather_Port">
<soap:address
location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port>
</service>
</definitions>


Using WSDL, a client can locate a Web service, and invoke any of the publicly available functions. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code. For example, check out the GLUE platform from the Mind Electric.
WSDL has been submitted to the W3C, but it currently has no official status within the W3C. See this W3C page for the latest draft.


8. What is UDDI?
UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web services protocol stack.
UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.
First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.
Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services.
The data captured within UDDI is divided into three main categories:
White Pages: This includes general information about a specific company. For example, business name, business description, and address.
Yellow Pages: This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.
Green Pages: This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.
You can view the Microsoft UDDI site, or the IBM UDDI site. The complete UDDI specification is available at uddi.org.
Beta versions of UDDI Version 2 are available at:
Hewlett Packard
IBM
Microsoft
SAP
9. How do I get started with Web Services?
The easiest way to get started with Web services is to learn XML-RPC. Check out the XML-RPC specification or read my book, Web Services Essentials. O'Reilly has also recently released a book on Programming Web Services with XML-RPC by Simon St.Laurent, Joe Johnston, and Edd Dumbill.
Once you have learned the basics of XML-RPC, move onto SOAP, WSDL, and UDDI. These topics are also covered in Web Services Essentials. For a comprehensive treatment of SOAP, check out O'Reilly's Programming Web Services with SOAP, by Doug Tidwell, James Snell, and Pavel Kulchenko.





1. What is XML?
XML is the Extensible Markup Language. It improves the functionality of the Web by letting you identify your information in a more accurate, flexible, and adaptable way.
It is extensible because it is not a fixed format like HTML (which is a single, predefined markup language). Instead, XML is actually a metalanguage—a language for describing other languages—which lets you design your own markup languages for limitless different types of documents. XML can do this because it's written in SGML, the international standard metalanguage for text document markup (ISO 8879).
2. What is a markup language?
A markup language is a set of words and symbols for describing the identity of pieces of a document (for example ‘this is a paragraph’, ‘this is a heading’, ‘this is a list’, ‘this is the caption of this figure’, etc). Programs can use this with a stylesheet to create output for screen, print, audio, video, Braille, etc.
Some markup languages (eg those used in wordprocessors) only describe appearances (‘this is italics’, ‘this is bold’), but this method can only be used for display, and is not normally re-usable for anything else.
4. Why is XML such an important development?
It removes two constraints which were holding back Web developments:
1. dependence on a single, inflexible document type (HTML) which was being much abused for tasks it was never designed for;
2. the complexity of full SGML, whose syntax allows many powerful but hard-to-program options.
XML allows the flexible development of user-defined document types. It provides a robust, non-proprietary, persistent, and verifiable file format for the storage and transmission of text and data both on and off the Web; and it removes the more complex options of SGML, making it easier to program for.
5. Describe the differences between XML and HTML.
It's amazing how many developers claim to be proficient programming with XML, yet do not understand the basic differences between XML and HTML. Anyone with a fundamental grasp of XML should be able describe some of the main differences outlined in the table below.
Differences Between XML and HTML
Table 1.
XML
HTML
User definable tags
Defined set of tags designed for web display
Content driven
Format driven
End tags required for well formed documents
End tags not required
Quotes required around attributes values
Quotes not required
Slash required in empty tags
Slash not required


1.What is JMS?
JMS stands for Java Messaging Service which is developed by Sun Microsystems . JMS Provider allow applications which are running on different systems can communicate with each other asynchronously . Many EAI tools support JMS as their standard messaging service.
3. What type messaging is provided by JMS?
Both synchronous and asynchronous.
4. How may messaging models do JMS provide for and what are they?
JMS provides for two messaging models, publish-and-subscribe and point-to-point queuing.
5. What is the point-to-point model in JMS?
A point-to-point model is based on the concept of a message queue: Senders send messages into the queue, and the receiver reads messages from this queue. In the point-to-point model, several receivers can exist, attached to the same queue. However, (Message Oriented Middleware)MOM will deliver the message only to one of them. To which depends on the MOM implementation.
6. What are the advantages of JMS?
One of the principal advantages of JMS messaging is that it's asynchronous. Thus not all the pieces need to be up all the time for the application to function as a whole.
7. What is the publish-and-subscribe model in JMS?
A publish-subscribe model is based on the message topic concept: Publishers send messages in a topic, and all subscribers of the given topic receive these messages.
9. What is publish/subscribe messaging?
With publish/subscribe message passing the sending application/client establishes a named topic in the JMS broker/server and publishes messages to this queue. The receiving clients register (specifically, subscribe) via the broker to messages by topic; every subscriber to a topic receives each message published to that topic. There is a one-to-many relationship between the publishing client and the subscribing clients.
12. What is the main parts of JMS applications?
The main parts of JMS applications are:
--ConnectionFactory and Destination
--Connection
--Session
--MessageProducer
--MessageConsumer
--Message


65. How does the Application server handle the JMS Connection?
1. App server creates the server session and stores them in a pool.
2. Connection consumer uses the server session to put messages in the session of the JMS.
3. Server session is the one that spawns the JMS session.
4. Applications written by Application programmers creates the message listener.

1. What is EJB?
EJB stands for Enterprise JavaBean and is a widely-adopted server side component architecture for J2EE. It enables rapid development of mission-critical application that are versatile, reusable and portable across middleware while protecting IT investment and preventing vendor lock-in.
9. What is Entity Bean and Session Bean ?
Session Bean is used to represent a workflow on behalf of a client. There are two types: Stateless and Stateful. Stateless bean is the simplest bean. It doesn't maintain any conversational state with clients between method invocations. Stateful bean maintains state between invocations.
Entity Bean is a Java class which implements an Enterprise Bean interface and provides the implementation of the business methods. There are two types: Container Managed Persistence(CMP) and Bean-Managed Persistence(BMP).

8. What is message-driven bean?
       A message-driven bean combines features of a session bean and a Java Message Service (JMS) message listener, allowing a business component to receive JMS. A message-driven bean enables asynchronous clients to access the business logic in the EJB tier
         A message bean is associated with a JMS topic or queue and receives JMS messages sent by EJB clients or other beans. Unlike entity beans and session beans, message beans do not have home or remote interfaces. Instead, message driven beans are instantiated by the container as required. Like stateless session beans, message beans maintain no client-specific state, allowing the container to optimally manage a pool of message-bean instances. Clients send JMS messages to message beans in exactly the same manner as they would send messages to any other JMS destination. This similarity is a fundamental design goal of the JMS capabilities of the new specification. To receive JMS messages, message driven beans implement the javax.jms.MessageListener interface, which defines a single onMessage() method.
============================================================================
What is SOAP?
SOAP is an XML-based communication protocol and encoding format for inter-application communication. SOAP is widely viewed as the backbone to a new generation of cross-platform cross-language distributed computing applications, termed Web Services.
Axis is essentially a SOAP engine -- a framework for constructing SOAP processors such as clients, servers, gateways, etc. The current version of Axis is written in Java, but a C++ implementation of the client side of Axis is being developed.
But Axis isn't just a SOAP engine -- it also includes:
  • a simple stand-alone server,
  • a server which plugs into servlet engines such as Tomcat,
  • extensive support for the Web Service Description Language (WSDL),
  • emitter tooling that generates Java classes from WSDL.
  • some sample programs, and
  • a tool for monitoring TCP/IP packets.

Using JAXB for XML data binding

Java™ Architecture for XML Binding (JAXB) is a Java technology that provides an easy and convenient way to map Java classes and XML schema for simplified Web services development. JAXB provides the xjc schema compiler, the schemagen schema generator and a runtime framework to support marshalling and unmarshalling of XML documents to and from Java objects.

About this task

JAXB is an XML-to-Java binding technology that enables transformation between schema and Java objects and between XML instance documents and Java object instances. JAXB technology consists of a runtime API and accompanying tools that simplify access to XML documents. You can use JAXB APIs and tools to establish mappings between Java classes and XML schema. An XML schema defines the data elements and structure of an XML document. JAXB technology provides tooling to enable you to convert your XML documents to and from Java objects. Data stored in an XML document is accessible without the need to understand the XML data structure.
JAXB is the default data binding technology used by the Java API for XML Web Services (JAX-WS) tooling and implementation within this product. You can develop JAXB objects to use within your JAX-WS applications. You can also use JAXB independently of the JAX-WS programming model as a convenient way to leverage the XML data binding technology to manipulate XML within your Java applications.

Using the JAXB runtime to marshal and unmarshal XML documents

Use the Java™ Architecture for XML Binding (JAXB) run time to manipulate XML instance documents.

Before you begin

Use JAXB to generate Java classes from an XML schema with the schema compiler, xjc command or to generate an XML schema from a Java class with the schema generator, schemagen command.

About this task

Use JAXB APIs and tools to establish mappings between an XML schema and Java classes. After data bindings exist, use the JAXB binding runtime API to convert XML instance documents to and from Java objects. Data stored in an XML document is accessible without the need to understand the data structure. JAXB annotated classes and artifacts contains all the information that the JAXB runtime API needs to process XML instance documents. The JAXB runtime API enables marshaling of JAXB objects to XML and unmarshaling the XML document back to JAXB class instances.

Procedure

  • Marshal JAXB objects to XML instance documents.
Use the JAXB runtime API to marshal or convert JAXB object instances into an XML instance document.
    1. Instantiate your JAXB classes.
    2. Invoke the JAXB marshaller.
This example demonstrates how to instantiate the generated JAXB objects within an application and use the JAXBContext class and the JAXB runtime marshaller APIs to marshal the JAXB objects into XML instances.
JAXBContext jc = JAXBContext.newInstance("myPackageName");
//Create marshaller
Marshaller m = jc.createMarshaller();
//Marshal object into file.
m.marshal(myJAXBObject, myOutputStream);
The JAXB Reference Implementation introduces additional vendor specific marshaller properties such as namespace prefix mapping, indentation, and character escaping control that are not defined by the JAXB specification. Use these properties to specify additional controls of the marshaling process. These properties operate with the JAXB Reference Implementation only and might not with other JAXB providers. Additional information regarding the vendor specific properties is located in the Java Architecture for XML Binding JAXB RI Vendor Extensions Runtime Properties specification.
  • Unmarshal XML files to JAXB objects.
Use the JAXB runtime API to unmarshal or convert an XML instance document to JAXB object instances.
    1. Obtain an existing XML instance document.
    2. Invoke the JAXB unmarshaller.
This example demonstrates a program that reads an XML document and unmarshals or converts the XML document into JAXB object instances. Use the JAXBContext class and JAXB runtime Unmarshaller APIs to unmarshal the XML document.
JAXBContext jc = JAXBContext.newInstance("myPackageName");
//Create unmarshaller
Unmarshaller um = jc.createUnmarshaller();
//Unmarshal XML contents of the file myDoc.xml into your Java 
  object instance.
MyJAXBObject myJAXBObject = (MyJAXBObject) 
um.unmarshal(new java.io.FileInputStream( "myDoc.xml" ));

Deploying Web services applications onto application servers

After assembling the artifacts required to enable the Web module for Web services into an enterprise archive (EAR) file, you can deploy the EAR file into the application server.

Before you begin

To deploy Java-based Web services, you need an enterprise application, also known as an EAR file that is configured and enabled for Web services. 

A Java™ API for XML-Based Web Services (JAX-WS) application does not require additional bindings and deployment descriptors for deployment whereas a Java API for XML-based RPC (JAX-RPC) Web services application requires you to add additional bindings and deployment descriptors for application deployment. JAX-WS is much more dynamic, and does not require any of the static data generated by the deployment step required for deploying JAX-RPC applications.

For JAX-WS Web services, the use of the webservices.xml deployment descriptor is optional because you can use annotations to specify all of the information that is contained within the deployment descriptor file. You can use the deployment descriptor file to augment or override existing JAX-WS annotations. Any information that you define in the webservices.xml deployment descriptor overrides any corresponding information that is specified by annotations. 

 

Difference between DOM and SAX



DOM: (Document Object Model)

1) Tree Based Xml parsing
2) Add Operations (Insert / Delete) while Parsing
3) Parse Backward and Forward
4) Takes Too much Memory
5) To make matters a little more confusing, you can also create your object model(s) on top of DOM. OOP is a wonderful thing.

SAX: (Simple API for XML)

1) Event Based Xml Parsing
2) Node by Node Reading
3) No Operation in b/w parsing
4) SAX is very Fast


Frequently Asked Programs in Interviews:

package com.jit;
/*
 * @author: Vinay Guntaka
 */
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.Scanner;

import com.jit.ConnectionUtil;

public class Demo {
    public static void main(String[] args) {
     
        printPyramidStarsNos();
        printPyramidStars();
    }
 
 
 
    /*      0
     *    123
     *  45678
     */
    private static void printPyramidStarsNos(){
        int n=3;
        int v=0;
        for (int i = 0; i < n; i++)
        {
            int stars = 1 + 2 * (i);
            int space = n - i;
            for (int j = 0; j < space; j++)
            {
                System.out.print(" ");
            }
         
            for (int k = 0; k < stars; k++)
            {
                System.out.print(v++);
            }
            System.out.println();
        }
    }
 
 
 
    /*
     * Enter value of t:
     * 6
     * 1 1 2 3 5 8
     */
    private static void printFibonacciNo(){
        Scanner input=new Scanner(System.in);
        int i,a=1,b=1,c=0,t;
        System.out.println("Enter value of t:");
        t=input.nextInt();
        System.out.print(a);
        System.out.print(" "+b);
        for(i=0;i<t-2;i++) {
            c=a+b;
            a=b;
            b=c;
            System.out.print(" "+c);
        }
        System.out.println();

    }
 
    /*
     *           *
     *        * * *
     *      * * * * *
     */
    private static void printPyramidStars(){
        int n=3;
        for (int i = 0; i < n; i++)
        {
            int stars = 1 + 2 * (i);
            int space = n - i;
            for (int j = 0; j < space; j++)
            {
                System.out.print("  ");
            }
         
            for (int k = 0; k < stars; k++)
            {
                System.out.print("* ");
            }
            System.out.println();
        }
    }
 
    private static void ReverseString(){
        String str = "Vinay Guntaka";
        // using pre-defined
        System.out.println(new StringBuffer(str).reverse());
        // using user-defined
        StringBuffer rev = new StringBuffer(str.length());
        for(int i=(str.length()-1);i>=0;i--){
            rev.append(str.charAt(i));
        }
        System.out.println(rev.toString());
    }
    private static void ReadLine() {
        Scanner sc = new Scanner(System.in);
        System.out.println(sc.next());
    }
    /*
     *    1
     *    2 3
     *    4 5 6
     */
    private static void getPyramid2() {
        int c = 0, n = 6;
        for (int i = 1; i <= n; i++) {
            for (int j = 1; j <= i; j++) {
                if (c != n)
                {
                    c++;
                    System.out.print(c + " ");
                } else
                    break;
            }
            System.out.print("\n");
        }

    }
 
    /*
     *    1
     *    21
     *    321
     *    4321
     */
    private static void getPyramid1(){
        int j=1;
        for(int i=1;i<=5;i++){
            for(j=i;j>0;j--){
                System.out.print(j);
            }
            System.out.println("");
        }
    }
 
    /* 1
     * 1 2
     * 1 2 3
     */
    private static void getNoPyramid(){
        for(int i=1;i<5;i++){
            for(int j=1;j<=i;j++){
                System.out.print(" "+j);
            }
            System.out.println("");
        }
     
    }
    private static void getGeneratedKeys(){

        Connection con = null;
        PreparedStatement pst = null;
        ResultSet rs = null;
        try {
            con = ConnectionUtil.getLocalConnection();
            pst = con.prepareStatement("INSERT INTO users(FIRST_NAME,LAST_NAME,PHONE_NUMBER,EMAIL_ADDRESS) VALUES('Vinay','Gutnaka','0000000000','vinay.gutnaka@gmail.com')");
            int st= pst.executeUpdate();
            // here i am retriving the last inserted id (which must be a primary key)
            if(st == 1){
                rs = pst.getGeneratedKeys();
            }
            if(rs.next()){
                System.out.println(rs.getInt(1));
            }
        } catch (Exception e) {
        }finally{
            ConnectionUtil.closeResultSet(rs);
            ConnectionUtil.closePreparedStatement(pst);
            ConnectionUtil.closeConnection(con);
         
        }
 
    }
}