从一种消息格式转换为另一种格式
这是我的要求。
我有一个客户端正在使用任何网络协议向某些软件服务提供商(ABC)发送特定的消息格式。
现在该客户正在切换软件服务提供商(XYZ),但不想更改其软件并希望继续发送 ABC 提供商的相同消息。
- 提供商 ABC 在某些古老的网络协议上使用某种基于位置的消息格式
- 提供商 XYZ 使用基于 HTTP(s) Web 服务的 XML,而不是 SOA 只是使用 XML 的简单 POST
- 某些值可以直接映射,而其他值必须重新计算或修改。例如,将客户的帐号从 ABC 提供商转换为 XYZ 提供商的帐号。这是用于请求和响应的。
- 过时的网络协议将在网络级别转换为 TCPI/IP,因此这不是问题。
- 客户期望实时响应。即:客户端发出请求,XYZ 执行任何操作并将响应返回给客户端。
因此,我需要创建某种隧道,接受 TCP/IP 将消息转换为 XML,将其通过 HTTP(s) POST 发送到 XYZ,获取 XML 响应,转换回基于位置,通过 TCPI/IP 回复给客户端。
这是 ESB 类型的事情吗?我应该编写某种 JAVA 服务器应用程序来执行此操作吗?
Here is my requirement.
I have a client that was sending a specific message format to some software service provider(ABC) using what ever network protocol.
Now this client is switching software service provider (XYZ) but does not want to change their software and wants to continue sending the same message of ABC provider.
- Provider ABC uses some sort of positional based message format over some archaic network protocol
- Provider XYZ uses XML over HTTP(s) web service not SOA just simple POST with XML
- Some values can be directly mapped while others must be recalculated or modified. For instance converting client's account number from ABC Provider to account number of XYZ provider. this is for request and response.
- The archaic network protocol will be converted to TCPI/IP at the network level so that is not an issue.
- The client expect a response in real time. I.e: Client makes request, XYZ does what ever and response back to client.
So I need to create some sort of tunnel that accepts TCP/IP converts the message to XML, sends it HTTP(s) POST to XYZ, get back XML response, convert back to positional based, reply back through TCPI/IP to the client.
Is this an ESB type thing, should I just write some sort JAVA server app that will do this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
你有太多的选择。从 Python、Perl 开始......有一些库/模块为您提供 TCP/HTTP/telnet/... 支持。使用它你可以做到这一点。
ESB 对此可能有点大材小用,它是一个用于大型集成的大型框架,但是您可以编写 BC(绑定组件)并执行它。性能 我不确定 ESB 是否会像 .pl/.py 这样更原始的东西一样好
。简而言之,有太多的选择。您必须根据部署环境来接听呼叫。
例如,您说“有些值可以直接映射,而其他值必须重新计算或修改。例如将客户的帐号从 ABC 提供商转换为 XYZ 提供商的帐号。这是用于请求和响应。”,如果 ABC-A/c-num 到 XYZ-A/c-num 的映射只能通过远程 EJB 调用获得,那么您可能需要考虑在 J2EE 中编写整个内容。如果您“计算”需要一些特定的库,您也必须考虑到这一点...
希望这不会使您的问题变得更糟..:)
PS:您应该开始接受之前问题的答案。正如霍姆所说。
You have too many options. Starting from Python, Perl.. there are libraries/modules that provide your TCP/HTTP/telnet/... support. Using that you can do this.
ESB might be an overkill for this, it's a big framework for big integrations, but yes you can write your BCs (Binding Components) and do it. Performance I'm not sure if ESB would be as good as something more primitive like .pl/.py
In short there are too many options. You have to take the call based on the environment in which you have to deploy it.
E.g. you said "Some values can be directly mapped while others must be recalculated or modified. For instance converting client's account number from ABC Provider to account number of XYZ provider. this is for request and response.", if ABC-A/c-num to XYZ-A/c-num mapping is only available via a remote EJB call then you might want to consider writing the whole thing in J2EE. If you "calculations" need some specific libs you have to factor that in as well...
Hope this doesn't make your problem worse.. :)
PS: You should start accepting answers to your previous questions. as Home said.
尝试过 Mule ESB,它的重量非常轻。我想说的甚至比它的一些竞争还要多。我喜欢它与 SOA 或肥皂没有特别的绑定。因此,您可以构建任何类型的端点,从普通的 TCP/IP、HTTP、文件、电子邮件到任何类型的端点,实际上它有十几个连接器,您甚至可以编写自己的连接器。我还喜欢这样一个事实:消息可以是任何内容。我可能是错的,但即使其他人声称他们有各种连接器和消息格式,他们似乎也有 SOAP 隐藏在引擎盖下的某个地方,这看起来很恶心哈哈,其他一些看起来不错,但文档很差。不喜欢某些基本 JDBC 功能仅在企业版中可用的事实。即:要从存储过程调用中获取输出参数,您需要企业版。
实际上,我可以选择任何允许我创建服务器来接收 HTTP 的服务器 API,然后编写代码来转换消息,打开与下一个服务的客户端连接,将其发送出去,接收响应,然后将其重新转换回来并返回给客户端。同时确保线程和队列在服务器内正常运行。也许我可以只使用 jetty 和 servlet,并在一个请求中完成所有操作。这是一个选项,但如果我必须切换到 TCP/IP,那么我只需稍微更改一下配置即可。等着看客户怎么说。
ESB 基本上就是粘合剂和管道。我所要做的就是编写三个自定义转换器类,因为我处理的消息是专有的银行格式,并且不完全映射到简单的 XSLT/XML 转换...以及大约 20 个 XML 标签将它们放在一起...
这就是我从 Mule 中获取它所需的全部内容(不包括构建我的数据源和 SQL 查询的标签)......
所以基本上......
1-接收带有自定义消息的 HTTP(s)
2-解析消息以获取客户号码
3- 在数据库中查找客户编号以获取其他服务的客户编号...
4- 创建新消息
5- 送去其他服务
6-将响应转换回来
7-返回给客户
Tried Mule ESB it's very light weight. I would say even more so then some of it's competition. I like how it's not particularly bound to SOA or soap. So you can construct any kind of end point from plain TCP/IP, HTTP, File, to Email to anything really it has more then a dozen connectors and you can even write your own. I also like the fact that the message can be anything. I could be wrong but even when others claim they have various connectors and message formats they seem to have SOAP somewhere hidden under the hood and it seems icky lol Some others seem good, but have poor docs. Didn't like the fact that some basic JDBC functionality is only available in the enterprise edition. I.e: To get Output parameters from your stored proc call you need the enterprise edition.
In reality I could have picked any server API that allowed me to create a server to receive HTTP, then write my code to transform a message, open a client connection to the next service send it off, receive the response, re-transform it back and return to the client. All while making sure threads and queues are behaving correctly within the server. Maybe I could have just used jetty and a servlet and do everything in one request. It's an option, but if I have to switch to TCP/IP then I just change the config a bit. Waiting to see what the client says.
The ESB is basically the glue and plumbing. All I had to do was write three custom transformer classes as the messages I deal with are proprietary banking formats and don't exactly map to simple XSLT/XML transforms... And about a 20 XML tags to put it all together...
This is all I needed to get this out of Mule (not including the tags to build my datasource and SQL query)...
So basically...
1- receive HTTP(s) with custom message
2- Parse message to get client number
3- Lookup client number in database to get client number for the other service...
4- Create the new message
5- Send off to other service
6- Transform response back
7- Return to client