0

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?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Piko
  • 4,132
  • 2
  • 21
  • 13

3 Answers3

0

Try XSLT trasformation in OpenESB.

Padmarag
  • 7,067
  • 1
  • 25
  • 29
0

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.

devmiles.com
  • 9,895
  • 5
  • 31
  • 47
0

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

Piko
  • 4,132
  • 2
  • 21
  • 13
  • Is LightRail available anywhere as open source, or would you consider making it available? – Haakon Oct 18 '11 at 12:32
  • Unfortunately, the development of LightRail has come at a great cost to my employer. As much as I would like to share, for the potential improvements that would likely come back from the open source community, I suspect my employer might not share the enthusiasm. LightRail has continued to evolve and is being used in one new project about every month or so. Perhaps once it reaches a better level of maturity, we can offer it as a product. :) – Piko Nov 04 '11 at 23:32