OpenESB 嵌套 BPEL？
我有一个不寻常的设计目标，我想使用 OpenESB 来解决它。我们有许多文件将由我们的系统生成并传输到另一个系统。根据数据类型、源系统和目标系统，在将数据上传到目标系统之前需要进行一系列转换。关于最佳方法有什么建议吗？
一般要求：
- 变换的数量和类型很多，并且可能随着时间的推移而变化。
- 随着时间的推移，要处理的数据的数量和类型将相当固定。
- 随着时间的推移，源系统和目标系统的数量可能会发生根本性的变化。
- 对于类型、源和目标相似的情况，这些转换中的每一个都可以组合在一起。
- 根据每个客户的业务规则，可能需要替换或插入新的转换到序列中，这将需要新的单独的序列。
- 解决方案需要尽可能灵活和可扩展。
- 许多基于类型、来源和目的地的未来要求可能会发挥作用，但我们尚未考虑。这种灵活性是系统的要求。
按照我们的想法，一组嵌套的 BPEL 似乎是最好的解决方案，每个 BPEL 调用一个 POJO 类来实现所需的转换。这可行吗？有更好的办法吗？
I have an unusual design goal that I would like to solve using OpenESB. We have a number of files that will be generated by our system to be transferred to another system. Depending on the data type, the source system and the destination system, a series of transforms will need to take place before the data can be uploaded to the destination system. Any advice on the best approach to this?
General requirements:
- The number and types of transforms are many and could change over time.
- The number and types of data to process will be fairly fixed over time.
- The number of source and destination systems could change radically over time.
- Each of these transforms could be ganged together for the cases where the type, source and destination are similar.
- Based on business rules from each customer, a new transform may need to be substituted or inserted in to the sequence, which would require a new and separate sequence.
- Solution needs to be as flexible and scalable as possible.
- Many future requirements based on type, source and destination could come in to play for which we have not yet considered. This flexibility is a requirement of the system.
In our way of thinking, it seems like a set of nested BPEL might be the best solution, each calling a POJO class to achieve the desired transform. Is this feasible? Is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
尝试在 OpenESB 中进行 XSLT 转换。
Try XSLT trasformation in OpenESB.
当涉及复杂的业务逻辑时，最好将尽可能多的工作委托给 Java 代码，而不是在 BPEL 中完成复杂的工作，因为随着业务的增长，BPEL 很快就会变得一团糟。
我只想创建一个 EJB 并从 BPEL 调用它。
When it comes to complex business logic it's best to delegate as much work as possible to Java code instead of doing complex stuff in BPELs which are really turn into a mess quickly as they grow.
I would just make an EJB and call it from BPEL.
我做了一个更好的。我从头开始编写了自己的数据流处理系统。其他可用的东西都太重量级和复杂了。
我的新系统，代号为 LightRail，运行良好。所有连接都是组件驱动的，并通过单个 JSON 配置文件定义。所有处理和流程控制都是通过单个 BeanShell 脚本处理的。
在过去 10 个月中，我已经部署了 10 个不同的数据流，连接到 IMAP、SFTP、FTP、文件和一两个数据库。生活又美好了......
安德鲁
I did one better. I wrote my own data flow processing system from scratch. Everything else available was just too heavyweight and complex.
My new system, code named LightRail, works great. All connectivity is component driven and defined through a single JSON configuration file. All processing and flow control is handled through a single BeanShell script.
I've already deployed 10 different data flows in the last 10 months, connecting to IMAP, SFTP, FTP, Files and a database or two. Life is good again...
Andrew