Interesting, a little salesy but, hey keep reading :-). It seems as if they are getting close to what we do but approaching it from the other direction, i.e. they've got a good J2EE server architecture and they're now moving into the SOA/ESB space. That's fair enough and a logical move given the current hype, they're using BPEL but have extended it it with BPELJ which is also good, the questions (in the interview) move towards WebServices and XML/SOAP for integration which is where we sort of meet up.
We come from the data and messaging layer, i.e. MOM and EAI, we provide small components (Integration Objects
). We replace XML and SOAP etc. with Java objects similar to XMLBeans. This doesn't generate big money since lots of people do similar things but we do get a lot of interest from companies (mainly banks) wanting high performance Java since we optimise the generated code to do just this, we also go way beyond the limitations of JAXB and Castor. Where the big money and OEM deals come from the fact that we also support SWIFT, FIX, CREST, FpML etc
So, where do they meet? Well we've started to "attach" rules to our Java Objects (messages), ECA (Event Condition Action) based rules, these can be executed in a distributed environment (J2EE, Jini JavaSpaces or both), we're strong supporters of pi-calculus, we were early members of BPMI and even wrote a BPML engine (which we dropped many years ago). Anyway, we're now seeing customers interested, although not yet committing, in BPEL and WebService Integration. So we're now starting to look at embedding our objects into SOAs like WebLogics as a "host".
I would therefore support BEA's path, in fact we're looking forward to meeting them somewhere along the way, I think our technologies complement each other quite well.