英文:
Using Jpos without Q2
问题
使用Jpos仅创建IsoMsg对象并使用通道、连接、发送和接收方法而不部署Q2的缺点是什么？
在我的Spring应用程序中，我使用Jpos来处理来自POS终端到不同交易处理器的金融交易。我的当前设置只涉及创建IsoMsg对象，设置所需字段，然后创建适当的通道，调用通道的发送和接收方法来处理交易。以下是我发送网络管理请求的示例：
ISOMsg m = new ISOMsg ();
m.setMTI ("0800");
m.set (3, "000000");
m.set (41, "00000001");
m.set (70, "301");
.......................................
.......................................
（省略了ISO消息的其他部分）
ISOChannel channel = new ASCIIChannel ("<processor_ip>", <processor_port>, new GenericPackager());
channel.connect();
channel.send(m);
IsoMsg response = channel.receive();
然而，Jpos程序员指南建议使用Q2而不是上述方法，但我发现Q2部署相当复杂且配置繁重。快速阅读程序员指南中的Q2部分会引入许多复杂的组件，其名称并不容易理解，如通道适配器、参与者、空间、过滤器、查询主机等。
我更喜欢使用简单的实现方式，即创建IsoMsg对象，通过通道打开连接，发送IsoMsg并接收响应。
我的问题是，相对于仅通过普通通道进行通信，使用简单的实现方式的缺点是什么，Q2部署相对于这种方法提供了哪些优势？
英文:
What are the downsides to using Jpos with just creating IsoMsg objects and using channels, connect, send, and receive methods instead of deploying a Q2?
I use Jpos in my spring application to process financial transactions from pos terminals to different transaction processors.
My current setup involves just creating an IsoMsg object, setting the required fields, then creating the appropriate channel calling the channel send and receive method to process the transaction like.
Below is an example of me sending a network management request:
ISOMsg m = new ISOMsg ();
m.setMTI ("0800");
m.set (3, "000000");
m.set (41, "00000001");
m.set (70, "301");
.......................................
.......................................
(other parts of iso message omitted)
ISOChannel channel = new ASCIIChannel ("<processor_ip>", <processor_port>, new GenericPackager());
channel.connect();
channel.send(m);
IsoMsg response = channel.receieve();
However the jpos programmers' guide recommends using a Q2 instead of the above method, but I find the Q2 deployment quite complex and configuration-heavy.
Reading the Q2 section of the programmers guide quickly introduces a lot of complex components with names that are not so easy to understand such as channel adaptors, participants, space, filters, query hosts, etc.
I prefer the simple implementation of creating an IsoMsg object, opening a connection through a channel, sending the IsoMsg, and receiving a response.
My question is, what are the downsides to using the simpler implementation over Q2, what advantages does the Q2 deployment offer over just communicating through plain channels
答案1
得分: 1
第一个缺点是处理时间。使用 Q2 中的 ChannelAdaptor，您始终保持通道连接，因此无需建立TCP/IP连接，这涉及到每个请求中的一些额外步骤。
此外，如果没有 Q2 和事务管理器，您必须实现所有的超时逻辑。例如，在您的代码片段中，如果另一端不响应，您没有处理超时。在某种其他方式重置连接之前，您的代码将被冻结。
您的代码很快就会足够复杂，尝试克服在jPOS团队积累的ISO8583交易处理实施的数十年经验中已经解决的挑战。
英文:
The first downside is processing time. With a ChannelAdaptor in Q2 you have the channel connected all the time, so you don't have the overhead of establishing the TCP/IP connection, which involves a few extra steps in each request.
Also, without Q2 and transaction managers, you have to implement all the timeout logic. For instance, in your code snippet, you don't handle a timeout if the other end doesn't respond. Your code would be frozen until the connection is reset by some other means.
Your code will be complex enough soon trying to overcome the challenges that are already sorted out in decades of experience of ISO8583 transaction processing implementation gathered by the jPOS team.
答案2
得分: 0
我建议你尝试一下这里描述的网关教程，你会发现使用Q2一切都变得更加容易。
顺便说一下，你可以只用几行代码从你的SB应用程序中运行Q2，看看这个Gist：
https://gist.github.com/ar/86a4a24384d029c35f784079007393b0#file-q2boot-java
英文:
I suggest you try the Gateway Tutorial described here, and you'll see that everything is quite easier with Q2.
And BTW, you can run Q2 from your SB application with just a few lines of code, take a look at this Gist:
https://gist.github.com/ar/86a4a24384d029c35f784079007393b0#file-q2boot-java
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论