Cliente Socket Web Service

No es lo mas recomendable ni lo mas refactorizable, escalable, etc. Pero quiza si es lo mas rapido.

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.Socket;
import javax.net.ssl.SSLSocketFactory;
import sun.misc.BASE64Encoder;

public class SendSMS_Soap {

	public static void main(String[] args) { 
		try { 
			String driver = "DRIVER-DATA; 
			String number = "NUMER-DATA"; 
			String login = "USER:PASS"; 
			String aut = (new BASE64Encoder().encodeBuffer(login.getBytes())).trim(); 

			String mensaje = "Probando envio de SMS con SOAP.."; 

			// ******************* Construimos el XML ******************* 
			String xmldata = //"<?xml version="1.0" encoding="UTF-8"?>"+ 
					"<soap:Envelope " +
					"xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" " + 
					// "xmlns:xsd="http://www.w3.org/2001/XMLSchema"  " +
					// "xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"" +
					">"+ 
			"<soap:Body>"+ 
			"<ns2:OPERACION xmlns:ns2="http://www.dominio.es/ruta/schemas">"+ 
			"<Version>1.0</Version>"+ 
			"<Authorization>"+aut+"</Authorization>"+ 
			"<Sender>"+driver+"</Sender>"+ 
			"<Recipients>" + 
			"<To>"+number+"</To>" + 
			"</Recipients>"+ 
			"<SMSText>"+mensaje+"</SMSText>"+ 
			"</ns2:OPERACION>"+ 
			"</soap:Body>"+ 
			"</soap:Envelope>"; 

			System.out.println("Mensaje a enviar: " + xmldata);
			// ******************* Creamos el Socket ******************* 
		
			System.setProperty("javax.net.ssl.trustStore", "trustStore.jks");
			SSLSocketFactory ssf = (SSLSocketFactory) SSLSocketFactory.getDefault();
		    Socket s = ssf.createSocket(SERVIDOR, PUERTO);
		    OutputStream outs = s.getOutputStream();
		    InputStream ins = s.getInputStream();

			// ******************* Enviamos la cabecera ******************* 
			BufferedWriter wr = new BufferedWriter(new 
					OutputStreamWriter(outs,"UTF-8")); 

			wr.write("POST /RUTA HTTP/1.1rn"); 
			wr.write("Content-Type: text/xml; charset=utf-8rn"); 
			wr.write("Accept: */*rn"); 
			//wr.write("Authorization: Basic "+aut+"rn"); 
			wr.write("User-Agent: Java/1.7rn"); 
			wr.write("Host: https://SERVIDOR:PUERTO/RUTA" + "rn"); 
			wr.write("Cache-Control: no-cachern"); 
			wr.write("Pragma: no-cachern"); 
			wr.write("SOAPAction: ''rn"); 
			wr.write("Connection: keep-alivern"); 
			wr.write("Content-Length: " + xmldata.length() + "rn"); 
			wr.write("rn"); 

			// ******************* Enviamos el XML ******************* 
			wr.write(xmldata); 
			wr.flush(); 
			
			// ******************* Esperamos respuesta y la sacamos por pantalla ******************* 
			BufferedReader rd = new BufferedReader(new InputStreamReader(ins)); 
			String line; 
			while((line = rd.readLine()) != null){
				System.out.println(line); 
			}

		} catch (Exception e) { 
			System.err.println(e.getMessage()); 
		} 
	}
	
}

Message Queue vs. Web Services?

En este post de stackoverflow. Copio y pego literalmente, para no perder esta informacion.

When you use a web service you have a client and a server:
– If the server fails the client must take responsibility to handle the error.
– When the server is working again the client is responsible of resending it.
– If the server gives a response to the call and the client fails the operation is lost.
– You don’t have contention, that is: if million of clients call a web service on one server in a second, most probably your server will go down.
– You can expect an immediate response from the server, but you can handle asynchronous calls too.

When you use a message queue like RabbitMQ, ActiveMQ, IBM MQ Series, Tuxedo you expect different and more fault tolerant results:
– If the server fails, the queue persist the message (optionally, even if the machine shutdown).
– When the server is working again, it receives the pending message.
– If the server gives a response to the call and the client fails, if the client didn’t acknowledge the response the message is persisted.
– You have contention, you can decide how many requests are handled by the server (call it worker instead).
– You don’t expect an immediate synchronous response, but you can implement/simulate synchronous calls.
Message Queues has a lot more features but this is some rule of thumb to decide if you want to handle error conditions yourself or leave them to the message queue.

En programmers.stackexchange.com encontre este otro post buscando cuando implementar RabbitMQ.

When to use Advanced Message Queuing Protocol like RabbitMQ?
Imagine that you have a web service that can accept many requests per second. You also have a accounting system that does a lot of things, one of which is processing the requests coming from the web service.
If you put a queue between the web service and the accounting system, you will be able to:
have less coupling between the two applications, because now both applications have to know the configuration parameters of the queue management system and the name of the queue. Here the catch is that usually you are more likely to move to another server some application than move the queue management system
if you have a lot of requests coming in a short amount of time, the accounting system will be able to process them all anyway
persist some requests if their number becomes really huge
Of course, you could have more complex situations where the number of your applications is much bigger than two and you need to manage the communication between them.