BEA’s Patrick discusses Project Free Flow

June 13, 2005—Paul Patrick is the chief architect for BEA Systems’ Project Free Flow product release. Project Free Flow is intended to enable deployment of services infrastructure for SOA (service-oriented architecture), with an enterprise service bus serving as a key component. Previously, Patrick worked on CORBA technology at Digital Equipment. InfoWorld editor at large Paul Krill recently interviewed Patrick about SOA, Project Free Flow, and other topics, including the company’s relationship with Java founder Sun Microsystems.

InfoWorld: Everyone is talking about SOA. How does BEA’s approach to SOA differ from the approach of competitors such as IBM or Sun Microsystems?

Patrick: What’s different is we’re taking a broader view of the problem than just Web services. We believe it really needs an infrastructure approach. A bus will take you to a certain point, but you need richer security, richer routing, richer management, and it’s typically found in most of the individual bus-type products. So we see it as bringing all of these pieces together and moving really up the curve, if you will, and focusing on the agility for IT to be able to react to changes in the business by making it easier to compose applications rather than code them.

InfoWorld: An enterprise service bus is featured in Free Flow. It’s been called QuickSilver. What do you see as the criticality of the enterprise service bus? There’s been debate in the industry about what exactly an enterprise service bus is and whether or not you need one.

Patrick: Well, an enterprise service bus filled some pretty significant voids. As enterprises start building services and the services begin to proliferate, one of the problems that can occur in a classic approach is a lot of point-to-point connections. And in making the point-to-point connections, applications are back down into riding very close to the plumbing level. A service bus can help address that point-to-point scenario, can help provide the abstraction so that an application developer can focus on the business logic itself, instead of on “How do I manipulate and deal with the plumbing that gets from point to point?” This allows for new versions of services and services that have lifecycle without having to perturb everybody in the communication path.

InfoWorld: I understand that Free Flow is intended to take BEA beyond Java. How is it going to do that and why do you see the need to do that?

Patrick: The reason Free Flow needs to go beyond Java is that the reality in most IT shops is that few, if any, are homogeneous. They’re not all J2EE shops or all .Net shops. They tend to have a mix. And as a result we have to come up with a way [to] tie these together. So it’s not about the best programming language or the best programming paradigm anymore. From a business standpoint, it’s how can I quickly, easily, and [with the] least amount of cost, solve a business problem by utilizing different technologies that I may already have and exposing them as services? And the realization is, because of this heterogeneity, there are a number of shops that—even if [they] are a J2EE shop—have multiple vendors’ [products]. The reality is we’ve got to make this all tie together, because this is really all about integration. Integration is not a homogeneous issue. It’s a heterogeneous type of problem.

InfoWorld: Why is integration so critical, and what’s happened that’s made it maybe a bigger problem now than it was before? I guess heterogeneity would have something to do with that.

Patrick: Part of it’s the heterogeneity problem that if we roll back to the ’90s and such, we really talked about what operating system we were focused on because we were HP shops or Sun shops or Microsoft shops or whatever, because we were coding at that very low level. The problem was we were all reinventing things again and again. Well, the application infrastructure wave came through and really changed that. It gave us the ability to do things in standard-based ways that made development easier. So the developers spent more time focusing on solving the business problem and less time focusing on writing [code]. And so in that wave came the CORBAs and the J2EEs and such. The problem that started happening is the realization that money was suddenly tight, the bubble had burst. People couldn’t continue to throw money at the problem, they had to start thinking, “How can I leverage the investments that I’ve made in the past and reutilize them in new and different ways?” Because they couldn’t afford to go back and rewrite their backend systems, which is really where they kept the company jewels and the information that was necessary. They couldn’t just go back and rewrite it, so they had to figure out how to reach back into those systems and unlock that information. Because those systems weren’t J2EE or CORBA or COM or anything like that, you immediately got into this heterogeneity type of problem of legacy systems, new systems, a mix of vendors, and a mix of technology.

InfoWorld: What do you see as Microsoft’s role in SOA? It doesn’t talk about it much. Where do you see it fitting in as maybe part of Free Flow or from a competitive viewpoint?

Patrick: Microsoft has a very strong Web presence via .Net. As such, what we keep seeing is that people on their desktop are already running Web services clients, [service] consumers, if you will. And a lot of them run and write those clients in .Net. But they’ve also got Unix boxes and mainframes and all other kinds of things. So Microsoft is another piece of that overall service ecosystem that is occurring. I think sometimes a lot of the industry thinks about them as being the desktop only, but they’ve also made some inroads using .Net in a service-based approach in the back room. So I think this is a realization when we think about Free Flow that .Net is there, it’s something that as an industry we can’t ignore. [It is] Web service-based so it can interoperate, because [Microsoft] too realized that it had to play with other people. And to play with other people on different platforms, interoperability was really the foundation that needed [to occur].

InfoWorld: BEA, IBM, and Microsoft have been working on a bunch of different Web services standards. Are there any more standards coming out? What about criticism that there are so many of these so-called standards and specifications that nobody can keep track of them all, and IT shops are only going to implement a couple of them anyway instead of the seemingly dozens out there?

Patrick: Right. All of us realize that standardization is critical, because without the standardization, interoperability is significantly hampered. There are a lot of specs. If you look at the specs, the key is that they’re for pieces of puzzles, and what the infrastructure vendors like BEA and such are going to need to do is to use those standards to solve those problems. A lot of people right now are using some of the open source Web services kits, if you will, and are now writing down to those lower-level specs themselves. And as those specs evolve, they can be fragile, and so part of this is, how do we as an industry get those things solidified and tied together? Instead of trying to build one spec for everything, define a set of building blocks on which to build things out of because not everybody will need everything.

InfoWorld: Are there any more specs coming out in any areas that haven’t been already covered?

Patrick: There are a number of specs that are yet to come out. Not all will make it to a standard. One of the things that is really critical is, if we’re going to have interoperability, we’ve got to start bringing some things together. There’s been some good movement in, for instance, Liberty moving SAML and some of the basic federation capabilities into OASIS. Even Microsoft in their descriptions and discussions about Active Directory Federation Services has embraced SAML (Security Assertion Markup Language) as one of the primary token types used in the federation scheme. So we’re beginning to see consolidation happening. And as that consolidation happens, we’ll better benefit the industry and the consumers.

InfoWorld: How would you describe BEA’s relationship with Sun? I guess it’s been kind of strained since Sun put the bundled app server in a version of Solaris. Would you call Sun a partner or a competitor?

Patrick: We still work very closely together. BEA is a member of the Java Community Process. We work with the other people in the Java Community Process to drive standards. There are other app servers out there. Sometimes it’s co-opetition. Sometimes, we’re working together. I don’t know that [Sun’s bundling] has made a significant impact on us, per se.

InfoWorld: Would you say that maybe it had the same impact as JBoss offering a free open source app server, or is there just no way to measure impact at this point?

Patrick: I don’t know that there’s a good way to measure it at this point.

InfoWorld: After project Free Flow comes out, where does BEA go from there?

Patrick: Well, Free Flow is not a one-shot thing. Free Flow will evolve and grow as we start looking deeper into the market as service infrastructure begins to expand. There are plenty of places and issues that need to be resolved, important things having to do with contact space routing. I mean, there’s a whole gamut of places to go. The question is, where are the right ones to go to and in which order? But we can think of a number of places that we’ll need to go, as well as expanding and enhancing and enriching our Free Flow offering.