Paul Patrick is the chief architect for BEA Systems" Project Free Flow product release, which is set to be formally unveiled June 9. Project Free Flow is intended to enable deployment of services infrastructure for SOA, 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, whether it be a consumer or a service [writer], 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: What was your role in the development of CORBA?
Patrick: I spent 14 years at Digital Equipment prior to it being acquired by BEA, where I was the architect for DEC"s CORBA ORB [object request broker], which BEA acquired. I"ve been involved in the definition of CORBA and various aspects of it throughout CORBA"s [history] as the premier object technology.
InfoWorld: BEA did not acquire DEC. I"m a little bit confused here.
Patrick: BEA acquired two products and engineering out of DEC. They acquired the Object Broker team, [which involved the] CORBA ORB, and they acquired the DEC Message Queue team, and that [provided] our messaging product. And those technologies, as well as people, were then folded into BEA"s products.
InfoWorld: A lot of people use CORBA, but I don"t think it ever got the critical mass that was expected. What was the issue there?
Patrick: There are differences between Web services predecessors, whether they were CORBA or Microsoft"s DCOM [Distributed COM] or anything, versus what we"re seeing with Web services. One of the first really obvious differences is that all of those models started by defining a programming model and then looked at interoperability, security, and management as a secondary or tertiary thing. If we think about what"s happened with Web services, the first thing that came out was in fact an interoperable protocol, followed by security and other things like WS-Security, XML digital signature, and XML encryption. Now [there is] work going on around management. That was one of the things. The second thing is there was still a battle going on out there in the world about not just [being] interoperable on the wire, but [also in] data representation. And XML was clearly [seen] as a better solution as it allows for the evolvability and the self-describing of data. That, you couldn"t necessarily easily do in CORBA.
InfoWorld: The problem we"re trying to solve here is integrating different applications and data, correct?
Patrick: Exactly. And so I think [the] Web services adoption rate has been accelerated over what we saw in CORBA mainly because it"s ubiquitous, right? We"ve got lots of vendors onboard, so unlike in the CORBA world, [where it is] really CORBA vs. J2EE vs. Distributed COM from Microsoft. And there was always this tension about were you a Microsoft shop or a CORBA shop or a J2EE shop. With Web services we"ve decoupled what operating system you run on or what programming paradigm for distributed computing do you use, and made it so that we can interoperate between these different things in a consistent and [unified] way. And the other big difference that occurred, and this was not necessarily a technological failure in CORBA but more of an issue of understanding, is that we realized that a lot of people [with] CORBA tried to do what they were doing with RPC but in an object-oriented fashion, and they were modeling things. And I think one of the things that"s come out with the Web services world [is] the concept [that] you"re not modeling objects, you"re modeling services [and] realizing that granularity had to be more coarse. That has helped also.
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 the world out there in most of the IT shops is 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 what"s 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 have already had and exposing them as services? And the realization is, because of this heterogeneity, there are a number of shops that -- even if [they] were a J2EE shop -- had multiple vendors" [products] in it. The reality is we"ve got to make this all tie together, because as you said, and we totally agree, 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 back-end 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. It is real out in the industry [and people are] using it. 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 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 that 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 WS 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. Well, you know as any of us, whether it"s Microsoft or IBM and BEA together driving some of the Web services security or reliable messaging or whether it"s management, whether it"s OASIS or W3C, I mean, 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 make usage of 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 überspec 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: I think throughout the industry we"re going to find that there are going to be additional specs that are emerging, some of them from IBM, BEA, Microsoft together, some from others. There are a number of things that are going on. There"s discussion about metadata exchange as being one of the specs. I"ve seen things around [such as] single sign-on. So there"s 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. Where 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 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 in that. 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 and we start looking at service-level agreements. 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.