我正在尝试用 Scala 编写一个程序，该程序将接受 SOAP 请求，从真实服务器获取响应（或从本地磁盘读取）并将数据返回给原始客户端。
我是 java/scala 生态系统的新手，所以我不知道该选择哪些库。 我听说 Scala 的 XML 处理非常好，所以我不知道我是否应该使用一些企业级的肥皂库/框架，如 jax-ws、jboss-ws、axis、cxf、xmlbeans 等。
基本上，我只需要
【问题讨论】：
代理服务器是异步/非阻塞 IO 的经典用例。如果我开始着手这个项目，我会先看一下Netty's HTTP support，然后先构建一个简单的反向代理（即将前端请求转发到后端服务器，并将后端响应转发到前端客户端），然后再继续协议翻译。
当涉及到协议转换时，您会招致 XML 解析器的愤怒。不幸的是，据我所知，没有一个好的、高性能、低占用空间的解析器可以原生处理异步 IO。其中相当一部分可能存在，但嵌入在商业产品中。请参阅this thread 了解更多信息。
但是，您可以通过使用通常依赖阻塞 IO 的 SAX 解析器来消耗“push-me-pull-you”管道的输出，从而以额外线程使用为代价“作弊”。由于服务器的 HTTP 部分是非阻塞的，因此您可以负担得起使用几十个线程来处理字节。
碰巧，我有been there, and done that。 :)
【讨论】：
SOAP 确实是一个可怕的规范，有很多不寻常的边缘行为的可能性。虽然 Scala 中的 XML 支持确实可以帮助您从头开始编写这样的库，但这仍然是一项重大工作（取决于您需要多少规范）。
同样，Jetty 背后也有多年的发展；处理您可能没有考虑过的性能需求和其他意外行为......甚至 Scala 最知名的 Web 框架 Lift 也正是因为这些原因在 Java Web 服务器上运行。它仍然非常适合与演员合作。
因此，此时，几乎可以肯定的是，使用经过验证的解决方案与 Java Web 服务器和现成的 Java SOAP 库会更好。为这些东西添加一个薄的 Scala 包装器的工作量将远远少于从头开始构建这些东西的工作量。
对于构建系统，sbt 是目前可用于 Scala 的最强大的工具，但如果您选择的 SOAP 库需要代码生成，您可能需要回退到 Maven。
最后，对于编辑器的选择。如果您对使用 Emacs 感到满意，那么 Ensime 插件就是令人惊叹的。如果您喜欢更传统的 Java IDE，那么 IntelliJ 目前似乎是最稳定的选择，但请注意这可能会很快改变。
【讨论】：
只是部分答案。
看看：
ant 的经验，我会推荐sbt
【讨论】：