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.