Test model and code excerpt for WEB services

The primary challenge for testing the effectiveness, performance, scalability, reliability, and security of Web Services is the distribution of Web services.

To enable complete Web services to achieve the desired functionality, clients and services are required to meet a range of requirements. Interfaces must be properly described in their WSDL documents, and messages must comply with transport protocol specifications (such as HTTP1.1) and message protocols (such as SOAP 1.1). The message must also conform to the contract in the WSDL document that describes the service, requiring that both the content of the message and the binding of the transport layer be considered. Combined with comprehensive security terms, interoperability issues, UDDI registration requirements, and performance requirements under a certain load, it is easy to see why network testing is not a trivial matter.

WEB Services components can be built and deployed together by multiple stakeholders. Therefore, testing these components will find it difficult to determine the quality of the code, availability, and so on. The standards of WEB services are simple, data-driven, and share a common xml-based base. Traditional test tools may not be sufficient to effectively test these standards. and GUI automation tools are not enough to effectively test the interface points and message formats of Web services.

Functional Testing

The goal of this test is fairly straightforward: Ensure that the server can send the correct response to a given request. However, because of the complexity of Web services, this task is not as simple as it might be. For most Web services, it is not possible to accurately anticipate what type of request the client will send. It is not practicable to enumerate all possible requests because the space that may be entered is either borderless or infinity. Therefore, it is extremely important to verify that the server can handle a wide range of request types and parameters.

Public Boolean execute (string action, string symbol, int quantity)
throws javax.xml.soap.soapexception{
Detail Detail = null;
Detail = Soapfactory.newinstance (). Createdetail ();
Detail.addchildelement ("Stock Trade"). Addtextnode ("failed");
System.out.println ("execute () in Webservices.stock.trade WebService has been invoked
with following arguments:: Action: "+ action +
" symbol: "+ symbol +" Quantity: "+ quantity);
if (action = null) {
throw new soapfaultexception (New QName ("Http://StockTrade/execute", "serverfailed"),
" Action parameter is null. ",
Null,
Detail);
}
if (symbol = = null) {
throw new soapfaultexception (New QName ("Http://StockTrade/execute", "serverfailed"),
" Symbol parameter is null. ",
Null,
Detail);
}
if (action.equalsignorecase ("buy"))
System.out.println ("BUYING Quantity:" + quantity + "of symbol:" + symbol); //Invoke method to execute trade here.
Else if (action.equAlsignorecase ("SELL"))
System.out.println ("Selling Quantity:" + quantity + "of symbol:" + symbol);
Invoke method to execute trade here.
Else
{
System.out.println ("INVALID Action:" + action);
throw new Soapfaultexception (New QName ("Http://StockTrade/execute", "serverfailed"),
"Invalid Action:" + action,< br> null,
detail);
}
return true;
}

Code excerpt: Stock Trade Web Services

The code for this excerpt is the implementation code for the "Execute ()" Method of the stock Trade WEB services. This method first verifies the validity of the input parameters and performs the function only if the validation succeeds. For example, if the parameter action is null, it throws a Soapfaultexception exception, using the FaultString argument (the second argument) to explain the cause of the exception. For illustrative purposes, the WEB services gives a processor after similar validation of the parameter symbol. In the actual case, the business logic should be implemented in this position:

try{
// Setup the global JAXM message factory
System.setProperty("javax.xml.soap.MessageFactory",
"weblogic.webservice.core.soap.MessageFactoryImpl");
// Setup the global JAX-RPC service factory
System.setProperty( "javax.xml.rpc.ServiceFactory",
"weblogic.webservice.core.rpc.ServiceFactoryImpl");
StockTrade_Impl ws = new StockTrade_Impl();
StockTradePort port　= ws.getStockTradePort();
boolean returnVal = port.execute(action, symbol, quantity);
System.out.println("The webservice got back the following result:" + returnVal);
}catch(Exception e) {
}

The above section of code describes how the test client activates the previously discussed stock Trade Web Services, which uses the Jax-RPC API (JAX Remoting Application interface function), And suppose that the reader's classpath already contains the necessary BEA supplied jar file. This is a static implementation where you can get an instance of a stub implementation. When a stub implementation is obtained, the "execute" method of WEB services is activated.