Multi-tiered technical support

Technical support is often subdivided into tiers, or levels, in order to better serve a business or customer base.

Tier/Level 1 (T1/L1)

This is the initial support level responsible for basic customer issues. It is synonymous with first-line support, level 1 support, front-end support, support line 1, and various other headings denoting basic level technical support functions.The first job of a Tier I specialist is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem. When analyzing the symptoms, it is important for the technician to identify what the customer is trying to accomplish so that time is not wasted on "attempting to solve a symptom instead of a problem." 

Tier/Level 2 (T2/L2)

This is a more in-depth technical support level than Tier I and therefore costs more as the techs are more experienced and knowledgeable on a particular product or service. It is synonymous with level 2 support, support line 2, administrative level support, and various other headings denoting advanced technical troubleshooting and analysis methods.Technicians in this realm of knowledge are responsible for assisting Tier I personnel in solving basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.However, prior to the troubleshooting process, it is important that the technician review the work order to see what has already been accomplished by the Tier I technician and how long the technician has been working with the particular customer. This is a key element in meeting both the customer and business needs as it allows the technician to prioritize the troubleshooting process and properly manage his or her time

 

Tier/Level 3 (T3/L3)

This is the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. It is synonymous with level 3 support, back-end support, support line 3, high-end support, and various other headings denoting expert level troubleshooting and analysis methods. These individuals are experts in their fields and are responsible for not only assisting both Tier I and Tier II personnel, but with the research and development of solutions to new or unknown issues. Note that Tier III technicians have the same responsibility as Tier II technicians in reviewing the work order and assessing the time already spent with the customer so that the work is prioritized and time management is sufficiently utilized. If it is at all possible, the technician will work to solve the problem with the customer as it may become apparent that the Tier I and/or Tier II technicians simply failed to discover the proper solution. Upon encountering new problems, however, Tier III personnel must first determine whether or not to solve the problem and may require the customer’s contact information so that the technician can have adequate time to troubleshoot the issue and find a solution

This team can analyze the code and data using information from Tier 1 and Tier 2.

 

Tier/Level 4 (T4/L4)

While not universally used, a fourth level often represents an escalation point beyond the organization. This is generally a hardware or software vendor. Within a corporate incident management system it is important to continue to track incidents even when they are being actioned by a vendor and the Service Level Agreement (SLA) may have specific provision for this. Within a manufacturing organization, the fourth level might also represent the Research & Development.

Web Service Axis2 and Eclipse

Setup the Development Environment

First you need to set up the development environment. Following things are needed if you want to create Web Services using Axis2 and Eclipse IDE. 

Some Eclipse versions have compatibility issues with Axis2. We tested with Apache Axis2 1.5.2, Eclipse Helios and Apache Tomcat 6.

1) Apache Axis2 Binary Distribution
2) Apache Axis2 WAR Distribution
3) Apache Tomcat
4) Eclipse IDE
5) Java installed in your Computer

1.2. Then you have to set the environment variables for Java and Tomcat. There following variables should be added.

JAVA_HOME :- Set the value to jdk directory (e.g. C:\Program Files\Java\jdk1.6.0_21)
TOMCAT_HOME :- Set the value to top level directory of your Tomcat install (e.g. D:\programs\apache-tomcat-6.0.29)
PATH :- Set the value to bin directory of your jdk (e.g. C:\Program Files\Java\jdk1.6.0_21\bin)

1.3. Now you have to add runtime environment to eclipse. There go to Windows –-> Preferences and Select the Server --> Runtime Environments.

There select Apache Tomcat v6.0 and in the next window browse your Apache installation directory and click finish.

1.4. Then click on the Web Service –-> Axis2 Preferences and browse the top level directory of Apache Axis2 Binary Distribution.

Creating the Web Service Using Bottom-Up Approach

2.1 First create a new Dynamic Web Project (File --> New –-> Other…) and choose Web --> Dynamic Web Project.

2.2 Set Apache Tomcat as the Target Runtime and click Modify to install Axis2 Web Services project facet.

2.3 Select Axis2 Web Services

2.4 Click OK and then Next. There you can choose folders and click Finish when you are done.

Create Web Service Class

Now you can create a Java class that you would want to expose as a Web Service. I’m going to create new class called FirstWebService and create public method called addTwoNumbers which takes two integers as input and return the addition of them.

3.1 Right Click on MyFirstWebService in Project Explorer and select New –-> Class and give suitable package name and class name. I have given com.sencide as package name and FirstWebService as class name.

package com.sencide;
public class FirstWebService { 
 public int addTwoNumbers(int firstNumber, int secondNumber){
  return firstNumber + secondNumber;
 }
}

3.2 Then, select File --> New –-> Other and choose Web Service.

3.3 Select the FirstWebService class as service implementation and to make sure that the Configuration is setup correctly click on Server runtime.

3.4 There set the Web Service runtime as Axis2 (Default one is Axis) and click Ok.

3.5 Click Next and make sure Generate a default service.xml file is selected. 

3.6 Click Next and Start the Server and after server is started you can Finish if you do not want to publish the Web service to a test UDDI repository.

You can go to http://localhost:8888/MyFirstWebService/services/listServices to see your running service which is deployed by Axis2. You can see the WSDL by clicking the link FirstWebService.

We have to use Eclipse every time when we want to run the service if we do not create .aar (Axis Archive) file and deploy it to the server. So let’s see how we can create it.

Create .aar (Axis Archive) file and Deploying Service

4.1 In your eclipse workspace and go to MyFirstWebService folder and there you can find our web service inside services folder. Go to that directory using command prompt and give following command. It will create the FirstWebService.aar file there.

jar cvf FirstWebService.aar com META-INF

4.2 Then copy the axis2.war file you can find inside the Apache Axis2 WAR Distribution (You downloaded this at the first step) to the webapps directory of Apache Tomcat. Now stop the Apache Tomcat server which is running on Eclipse IDE. 

4.3 Using command prompt start the Apache Tomcat (Go to bin directory and run the file startup.bat). Now there will be new directory called axis2 inside the webapps directory. Now if you go to the http://localhost:8080/axis2/ you can see the home page of Axis2 Web Application.

4.4 Then click the link Administration and login using username : admin and password : axis2. There you can see upload service link on top left and there you can upload the created FirstWebService.aar file. This is equal to manually copping the FirstWebService.aar to webapps\axis2\WEB-INF\services directory.

4.5 Now when you list the services by going to http://localhost:8080/axis2/services/listServices you should be able to see our newly added service.

Creating a Web service client

5.1 Select File --> New --> Other… and choose Web Service Client

5.2 Set he newly created Axis2 Web service (http://localhost:8080/axis2/services/FirstWebService?wsdl) as the Service definition. Then configure the Server runtime as previously and click finish. 

5.3 This will generate two new classes called FirstWebServiceStub.java and FirstWebServiceCallbackHandler.java. Now we can create test class for client and use our web service. Create new class called TestClient.java and paste following code.

package com.sencide;

import java.rmi.RemoteException;
import com.sencide.FirstWebServiceStub.AddTwoNumbers;
import com.sencide.FirstWebServiceStub.AddTwoNumbersResponse;

public class TestClient {

 public static void main(String[] args) throws RemoteException {
  
  FirstWebServiceStub stub = new FirstWebServiceStub();
  AddTwoNumbers atn = new AddTwoNumbers();
  atn.setFirstNumber(5);
  atn.setSecondNumber(7);
  AddTwoNumbersResponse res = stub.addTwoNumbers(atn);
  System.out.println(res.get_return());
  
 }
}

Deploying Java Class as a Web Service in Axis2

We assume that we want to publish the following HolaWorld class as a Web serviceHelloService.

public class HolaWorld {
   public String sayHello(String name) {
      return "Hello " + name;
   }
}

Our HelloService will provide one operation, sayHello, that takes name as the input and returns the "Hello ..." string as the output.
There are two main steps involved in publishing a Web service from your Java code:

1. Write a service description file (services.xml).
2. Create a service archive file.

Writing the services.xml file

Once Axis2 receives a request to a Web service, it has to figure out which Java class can handle the Web service request. This "mapping" between a Web service and a Java class is described inservices.xml file. Writing the services.xml file for our HelloService is quite simple. Essentially, the file should contain the following information:

• Fully qualified class name that handles the published Web service
• Message receiver used by the Web service

For now, do not worry about the message receiver part, and look at the following services.xml file for our HelloService:

   This is the HolaWorld service
   HolaWorld
   
      
   

The second line in the above file provides a text description of the Web service and may be omitted.
Service implementation class: The third line indicates that this Web service is handled by the HolaWorld class. Since our HolaWorld class does not belong to any package namespace, the class name is specified simply as HolaWorld here, but in general the class name should be the fully qualified class name (like edu.ucla.cs.cs144.DemoService).
Message receiver: The fourth through sixth lines specify that the operation sayHello of this service should use the Axis2 Java class org.apache.axis2.rpc.receivers.RPCMessageReceiver as its message receiver class. A message receiver is the Axis2 Java class that processes the inputs to and outputs from the Web service, and pass them to/from our Java class. Axis2 provides a set of built-in message receiver classes depending on the message exchange pattern (MEP) of the Web service (e.g., input only? output only? input and output?) and the input/output encoding scheme used by the service; in our example, we are using org.apache.axis2.rpc.receivers.RPCMessageReceiver which is a common message receiver used for publishing an existing Java class.

Different way of specifying message receivers

In the above services.html file, we specified the Axis2 message receiver class at the operation level, associating a message receiver for every operation of our service. Axis2 also allows us to specify the message receivers at the service level, so that we can specify the message receiver once for the entire service as follows:

   This is the HolaWorld service
   HolaWorld
   
       
       
   
   

Note that Axis2 has built-in support for all the eight MEPs (Message Exchange Pattern) defined in WSDL 2.0. In the services.xml file, we can specify the MEP and the corresponding message receiver, and then, Axis2 automatically picks up and uses the appropriate message receiver for each service operation. In the above file, we specify RPCInOnlyMessageReceiver as the message receiver for all input-only operations and RPCMessageReceiver as the message receiver for all input-and-output operations.
In the second last line, the operation element for sayHello shows this operation will be available by the service. This line is optional; by default, Axis2 exposes all public methods in the service implementation class whether we specify them in services.xml or not. For all public methods in the implemenation class, Axis2 calculates the MEP of the operation by checking the return value of the Java method. If the method is void, the MEP will be in-only; else, it will be in-out, depending on which the appropriate MEP message receiver will be set.

Creating a service archive file

Once we create our service description file services.xml, the final step before deployment is to create a service archive file by putting together (1) our service implementation class, (2) all libraries that it depends on, and (3) the services.xml file. These files should be placed in the appropriate directories within the archive file. For example, the directory structure of our HelloService archive file should be as follows:

HelloService.aar
 +- META-INF
 |    +- services.xml
 |
 +- HolaWorld.class

First note that the name of the archive file is HelloService.aar, which is the same as the name of the Web service that the archive file provides, followed by the extension .aar. If the name of our service were MyService, the file name would have been MyService.aar.
The services.xml file that we created in the previous step should be placed in the META-INF subdirectory of the archive file.
Depending on the namespace the class belongs to, the service impelementation class should be placed in the appropriate subdirectory of the archive file. In our example, the HolaWorld class does not belong to any package namespace, so it is simply placed at the root directory. All other classes that the implementation class depends on should also be placed at the appropriate directory.
Finally, if the implementation class uses any external Java libraries, they should be placed in the lib subdirectory of the archive file.
Here is a bit more complex example of the structure of an archive file:

AnotherService.aar
 +- META-INF
 |   +- services.xml
 |
 +- lib
 |   +- xxx.jar
 |
 +- edu
     +- ucla
         +- cs
            +- cs144
                +- AnotherClass.class

Here, the archive file handles the Web service named AnotherService and the service is implemented by the Java class edu.ucla.cs.cs144.AnotherClass. Assuming the class depends on the xxx.jarlibrary, we placed it in the lib subdirectory of the archive file.
An archive file can be created using the jar command in the stadard Java Development Kit. For example, to create the above HolaWorld.aar file, first (1) create a temporary directory, (2) create the appropriate subdirectories within the temporary directory (like META-INF, lib, etc.), (3) place your class and library files at the appropriate subdirectories. Then inside the temporary directory, execute the following command:

jar cvf HelloService.aar *

The above command will create the HelloService.aar file and add all files below the current directory to the file. Once the archive file is created, deploying the service is just a matter of dropping the service archive file into the services directory in our Axis2 server repository. We can also easily upload the service archive file by using axis2 Web administration console.