Ich versuche, ein Programm in Scala zu schreiben, das SOAP-Anfragen akzeptiert, die Antwort vom realen Server bekommt (oder von der lokalen CD liest) und die Daten an den ursprünglichen Client zurückgibt.
Ich bin neu im Java / Scala-Ökosystem, also habe ich keine Ahnung, welche Bibliotheken ich wählen soll. Ich habe gehört, dass Scalas XML-Behandlung recht nett ist, also weiß ich nicht, ob ich irgendeine Enterprise-Soap-Bibliothek / Framework wie jax-ws, jboss-ws, axis, cxf, xmlbeans usw. verwenden sollte.
Im Grunde brauche ich nur
SOAP ist wirklich eine scheußliche Spezifikation, mit viel Potenzial für ungewöhnliches Randverhalten. Obwohl es stimmt, dass XML-Unterstützung in Scala Ihnen helfen würde, eine solche Bibliothek von Grund auf neu zu schreiben, wäre dies immer noch ein großer Aufwand (abhängig davon, wie viel von der Spezifikation Sie benötigen).
Ebenso hat Jetty jahrelange Entwicklung hinter sich; Umgang mit Performance-Anforderungen und anderen unerwarteten Verhaltensweisen, die Sie wahrscheinlich nicht in Betracht gezogen haben ... Selbst das bekannteste Web-Framework von Scala, Lift, läuft aus genau diesen Gründen auf einem Java-Webserver. Es funktioniert immer noch sehr glücklich mit Schauspielern.
Zu diesem Zeitpunkt ist es Ihnen mit Sicherheit besser, eine bewährte Lösung mit einem Java-Webserver und einer Java SEAP-Bibliothek zu verwenden. Der Aufwand, um eine dünne Scala-Wrapper um diese hinzuzufügen, wird weit weniger als die Mühe, diese Dinge von Grund auf neu zu bauen.
Für das Build-System ist sbt das leistungsfähigste Werkzeug, das derzeit für Scala verfügbar ist, aber Sie müssen möglicherweise auf Maven zurückgreifen, wenn dies für die Code-Generierung durch Ihre ausgewählte SOAP-Bibliothek erforderlich ist.
Schließlich für die Wahl des Editors. Wenn Sie mit Emacs zufrieden sind, ist das Ensime-Plugin einfach erstaunlich . Wenn Ihnen eine konventionellere Java-IDE gefällt, dann scheint IntelliJ derzeit die stabilste Option zu sein, obwohl Sie sich bewusst sein sollten, dass sich dies sehr schnell ändern könnte.
Nur eine teilweise Antwort.
Schau dir an:
ant haben Ich würde sbt empfehlen
Proxy-Server sind ein klassischer Anwendungsfall für asynchrone / nicht-blockierende IO. Wenn ich an diesem Projekt teilnehmen würde, würde ich mich zunächst einmal mit einem Blick auf Nettys HTTP-Unterstützung und Erstellen eines einfachen Reverse-Proxies (dh Weiterleiten von Front-End-Anfragen an Backend-Server und Backend-Antworten an Frontend-Clients), bevor die Protokollübersetzung fortgesetzt wird.
Wenn es an der Zeit ist, an der Protokollübersetzung zu arbeiten, werden Sie den Zorn der XML-Parser erleiden. Leider gibt es meines Wissens keinen guten Parser mit hoher Performance und geringem Platzbedarf, der asynchrone IO nativ verarbeitet; einige davon existieren wahrscheinlich, sind aber in kommerzielle Produkte eingebettet. Siehe dieser Thread für weitere Informationen.
Sie können jedoch auf Kosten zusätzlicher Thread-Verwendung "schummeln", indem Sie einen SAX-Parser verwenden, der normalerweise auf das Blockieren von IO angewiesen ist, um die Ausgabe einer "Push-Me-Pull-You" -Pipeline zu konsumieren. Da die HTTP-Teile Ihres Servers nicht blockierend sind, können Sie es sich wahrscheinlich leisten, ein paar Dutzend Threads zu verwenden, nur um Bytes zu schaufeln.
Wie es passiert, war ich dort und habe das gemacht . :)