Procedure 7.2. Task

• As soon as we have the Message definitions supported by the service, we can construct the client code. The business logic used to support the service is never exposed directly by the service (that would break one of the important principles of SOA: encapsulation). This is essentially the inverse of the service code:

  		  ServiceInvoker flightService = new ServiceInvoker(...);
  Message request = // create new Message of desired type
  
  request.getBody().add(“org.example.flight.seatnumber”, ”1”);
  request.getBody().add(“ org.example.flight.flightnumber”, “BA1234”);
  
  request.getHeader().getCall().setMessageID(1234);
  request.getHeader().getCall().setReplyTo(myEPR);
  
  Message response = null;
  
  do
  {
  	response = flightService.deliverSync(request, 1000);
  	
  	if (response.getHeader().getCall().getRelatesTo() == 1234)
  	{
  	// it's out response!
  	
  	break;
  	}
  	else
  	response = null;  // and keep looping
  	
  } while !maximumRetriesExceeded();
  

  Note

  Much of the above will be recognizable to readers who have worked with traditional client/server stub generators. In those systems, the low-level details (such as the opcodes and the parameters) are hidden behind higher-level stub abstractions. SOA Platform has integration with RESTEasy that enables a user to develop annotation based REST style web services. These hide the low level details such as opcodes and parameters.