SOAP-proxy en Scala: ¿qué necesito?

Question

Estoy tratando de escribir un programa en Scala, que aceptará solicitudes de jabón, obtener la respuesta del servidor real (o leer desde el disco local) y devolver los datos al cliente original.

Soy nuevo en el ecosistema Java/Scala, así que no tengo ni idea, lo que las bibliotecas para elegir. Escuché que el manejo de XML de Scala es bastante bueno, así que no sé si debería usar algún enterprise-soap/library como jax-ws, jboss-ws, axis, cxf, xmlbeans, etc.

básicamente, sólo necesito

• una biblioteca, que acepta las solicitudes (en la actualidad, estoy mirando jetty, pero preferiría algo que soporta de forma nativa actores. scala-http parece que cubrir, pero no es la producción -ready o mantenerse, para el caso)
• alguna biblioteca para solicitar los datos desde el otro servidor (algo así como rizo, libwww-perl para java/Scala)
• un sistema de compilación (¿hormiga? SBT?)
• un IDE (estoy acostumbrado a eclipsar, pero el apoyo Scala de IntelliJ se supone que es mejor)
• una herramienta para probarlo (en la actualidad, estoy usando SoapUI)

Answer 1

SOAP es verdaderamente una especificación horrible, con mucho potencial para el comportamiento inusual franja. Si bien es cierto que el soporte de XML en Scala te ayudaría a escribir una biblioteca así desde cero, aún así sería un gran esfuerzo (dependiendo de la cantidad de especificaciones que necesites).

Del mismo modo, Espolón tiene años de desarrollo detrás de él; lidiar con las demandas de rendimiento y otros comportamientos inesperados que probablemente no haya considerado ... Incluso el marco web más conocido de Scala, Lift, se ejecuta sobre un servidor web Java por estas mismas razones. Todavía funciona muy feliz con los actores.

Por lo tanto, , en este momento en el tiempo, es casi seguro que es mejor utilizar una solución probada con un servidor web Java y una biblioteca Java SOAP. El esfuerzo de agregar una delgada capa de Scala alrededor de estos será mucho menor que el esfuerzo de construir estas cosas desde cero.

Para el sistema de compilación, sbt es la herramienta más poderosa actualmente disponible para Scala, pero es posible que necesite recurrir a Maven si esto es necesario para la generación de código de su biblioteca SOAP elegida.

Por último, para la elección del editor. Si está contento con Emacs, el complemento de Ensime es solo increíble.Si un IDE de Java más convencional es de su agrado, entonces IntelliJ actualmente parece ser la opción más estable, aunque tenga en cuenta que esto podría cambiar muy rápidamente.

Answer 2

Sólo

una respuesta parcial.

Mira:

• HttpClient para hacer peticiones HTTP
• sistema de construcción, si usted no tiene experiencia previa con ant recomendaría sbt
• Para el IDE, que tenía buen éxito con IntelliJ una hace unos meses. Creo que Eclipse ha mejorado, pero no sé cuánto.
• SoapUI todavía funciona perfectamente

Answer 3

servidores proxy son un caso de uso clásico para asíncrono sin bloqueo IO /. Si estuviera de embarcarse en este proyecto, me gustaría empezar por echar un vistazo en profundidad a Netty's HTTP support y construir un simple proxy inverso (es decir, reenvía las solicitudes a los servidores frontend backend, y las respuestas de back-end a los clientes frontend) primero antes de pasar al protocolo de traducción .

Cuando llega el momento de trabajar en la traducción de protocolos, incurrirá en la ira de los analizadores XML. Lamentablemente, que yo sepa, no existe un analizador sintáctico bueno, de alto rendimiento y de baja huella que maneje de forma nativa el IO asíncrono; bastantes de ellos probablemente existen pero están integrados en productos comerciales. Vea this thread para más información.

Sin embargo, puede "engañar", a costa de un uso adicional de subprocesos, mediante el uso de un analizador SAX, que normalmente depende del bloqueo de IO, para consumir la salida de una canalización "push-me-pull-you". Debido a que las partes HTTP de su servidor no son bloqueantes, probablemente pueda permitirse utilizar algunas docenas de hilos para traspasar bytes.

Da la casualidad, tengo been there, and done that. :)