Adam Bosworth, vice president of engineering of the Frameworks Division at BEA, recently sat down with JP Morgenthal to talk about his role in WebLogic.

WLDJ: Tell us about your role at BEA.
Adam: Basically, I make sure that we build what's necessary for J2EE to become usable by the rest of us - on top of WebLogic Server. Whether it's building the user interface in the portal strategy, or building the overall development environment, WebLogic Workshop will make it easy for every reasonable developer to use.

WLDJ: What are your primary software development interests?
AB: I've spent my life trying to make building applications easy. Basically, helping developers build solutions - developing products, plumbing, or technology to help them build solutions. Whether it was Active Server Pages and the extent of my work at Microsoft, all of which was plumbing, or Access and working on the VB products, I helped them build the application. That's what I like doing.

WLDJ: What are the biggest challenges facing the developer community?
AB: We're moving into an era when more of the information on the Web will come to you, rather than you going out to it. Today we have a pull model. When you want to get information, you go to a site and pull the information out; information doesn't come to you. As we move into a world of mobile devices and applications interacting with each other, the pull model will become one of two models - push-and-pull architecture. A big challenge is in making it easy for developers to write and manage, and then administer and configure applications where the applications don't just provide information on demand, but send information to people.

Another challenge, even in building WebLogic Workshop, is making asynchronous Web services the linchpin of the product. Coming up with the right programming model and making it easy was critical. We were able to work with mobile vendors and cut deals in weeks because they could see the opportunity for sending information to the devices. A big challenge is making the shift from a pull-model world to a push-pull model. Also, we've built a large infrastructure for building complex Web-based apps, but most people don't have a good way to understand what the application is doing.

When you build a Web site you want to build four kinds of logic. There's logic that describes the overall site: what pages are brought up when, possible navigations, and how they depend on who you are and what you've done. That's site-level logic.

Then there's page-level logic. The user just filled these fields in. What should I do? How do I update my portfolio or my sales course automation?

Layout logic: What does the page look like? How conditional is that based on personalization and other things?

Finally, there's business logic. Right now, it's hard for developers to know where to put that logic, so they put it all in one place. You can't tell at any high level what's going on. I hear that it's happening in the .NET world as well. Making the business logic easy to separate and easy for business analysts who work with developers, so you can see the overall layout and flow of your logic and partition it in a natural and intuitive way, is the other major challenge we're facing. BEA's Framework Division is building products that provide solutions to these challenges.

WLDJ: How do you make partitioning easy?
AB: We're working with Java- Server Faces - working group JSR1-27. .NET has done it with controls. You can have UI code behind the page and that page code becomes strictly layout logic; the two can coexist. You can separate easily from your layout logic, which is just JSP in our world, and there will be code behind it. It's a baby step, but then you need an IDE to make it easy to use.

Another example is what we did in WebLogic Workshop with a two-part view. You can see what's going on in the Web service using the design view. Then you can go to the code. How do you handle incoming messages? The code is straight Java; you can toggle between the two views. Annotations make this possible. Metadata is becoming important because it can describe to the IDE what's going on and let the IDE provide higher-level views, like the design view in WebLogic Workshop. Another example is business process management.

WLDJ: Do you foresee the facility, like in C#, to store attributes as one of those areas?
AB: We've already done that in WebLogic Workshop. We use annotations and comments. JSR-175 has been submitted just for adding annotated metadata to Java. In addition, we submitted JSR-181, which is the JWS JRS itself and formalizes it for this particular case (Web services). The only difference is that in .NET it was done intrusively into the language. We do it more quietly, in comments. Endemically, in WebLogic Workshop we use metadata all over, in just that way, as attributes.

WLDJ: BEA has announced the BEA WebLogic Enterprise Platform and integrated stack based on WebLogic Server, which offers a single platform for Web services, portal, and integration capabilities. Why did BEA push to have a single application infrastructure?
AB: It's what developers need. It has scale. Once our customers put an outward face on an app, they need it to be available 24/7. You need high availability and complete reliability, hence the need for transactions. If you take those three needs - scalability, high availability, and transactions - you've got an app server. It's the kernel you need for pretty much any function I can imagine deploying today.

Portals, integration, and Web services are all part of the same thing. Customers have invested in IT over the last 10 years and built thousands of applications. We have customers that haven't been able to treat all these applications as intelligent resources they can integrate for both information and process. Now they're looking to build portals that act as UI integration layers that pull together the information in a personalized, customized way.

For their customers, employees, or partners, they're looking to pull together business processes so all the other application servers are either sources of information or integral parts of the overall process. To do this, they're looking for the same kind of integration and high-availability scalability and transactions because they're mission-critical applications. If anything goes down or the system stops working, they stop delivering services to their customers, themselves, or their suppliers and partners.

This is the difference between how we look at integration and how other companies do, which is through business process management (BPM). I've seen a lot of people writing messages in integration brokers. They think of the message integration broker as just a switch that takes an incoming message and routes it to the right place. When we look at how our customers use BPM, they're integrating facilities within the app itself. They're calling EJBs at every step. The workflow is deeply integrated with how they choreograph and run the various components of the application. That's much easier to do with one integrated stack. It's hard to provide that kind of seamless integration from the outside.

That's an argument for a single platform. When you build one of these pieces everything is integrated, but it goes a little further. People are using Web services more to build the next generation of integration. I talk to companies making major bets on their EI system being replumbed on top of Web services over the next 12 to 24 months. They're asking themselves, "How do we wire the application logic to invoke or be invoked by these Web services? How do we work the UI logic to do the same?" They want it to be one seamless whole so they can also wire it into their user interface, but don't want to easily expose any functionality in the application. It's a fancy way of saying, "We need a single platform because our customers need it, because the applications they're building are about integrating information."

WLDJ: What part has BEA's acquisition of Crossgain played in providing BEA's unified application infrastructure?
AB: We've chosen to build something where the average corporate developer could focus on business logic and application logic, not plumbing. We saw an opportunity to increase use of J2EE if we could let people focus on the business application logic. Crossgain chose to start with Web services. Their role was to make Web services easy for developers in a way that fully exploited the J2EE platform. Our acquisition of Crossgain led to WebLogic Workshop. It's an environment that makes it easy to build truly enterprise-ready Web services. Crossgain and BEA had to do a lot of work to make sure that Web services lived up to what the enterprise would need.

WLDJ: Crossgain was based on a Web services platform? How viable is Web services technology, whether it's .NET or Java?
AB: Web services are extremely viable for one arena and becoming viable for another. They're extremely viable for integrating information within an enterprise. To do that, you need three things. You need coarse-grained messaging. You get that from Web services. You need a loosely coupled model because applications across the enterprise are run by different departments and groups and none of them can be redeployed in concert. You need to be sure that changing one application won't break the others. You need an asynchronous model because a great deal of what the applications do is such that you cannot assume that you can invoke them synchronously, either because they aren't available all the time or because there are peak loads that would overload your service.

You also need reliable messaging, which isn't yet part of the Web services standard, but most enterprises are wired up to a message bus. There are bridges between message buses and we made JMS a transport for Web services. In doing so, we guaranteed that within the enterprise you could have reliable delivery, even within the context of Web services using JMS as the transport for the message buses rather than using HDDP. Now we give you a choice - use one, both, or either.

Security isn't as rich and well defined as it should be at this stage. Within the enterprise, security constraints were more manageable because you were safe within your firewalls. Some of the tools that are already there - right at your sign-in, unsign-in using XKMS or SSL - are reasonable to do within the enterprise. If you look at where Web services are on B2B, that's where these adages are felt most keenly. The two things that are slowing down Web services' adoption to the B2B space are the lack of standards for reliable messaging and an automatic assumption that all the stacks that implement Web services implement reliable messaging.

WLDJ: You said earlier that there's an assumption about the security model. What is it?
AB: Within the enterprise you tend to assume that someone who's made it within the firewall isn't dangerous. That doesn't mean they aren't dangerous; they aren't as dangerous as when you open things up through the firewall. You realize someone coming into this organization could be malignant because the code coming in isn't code written by your organization. That raises the ante dramatically. In one case you can do reasonable checks and balances and have speed bumps to catch people who are just being sloppy on permissions and rights. The other case, when you really have to be completely confident that you have very hard-core security, is on the security across companies where people coming in simply aren't trusted in the same way because they don't work for you. That's where the demand goes up dramatically. We've been working with VeriSign and others to draft a new security directive that's come out of Microsoft, VeriSign, and IBM.

WLDJ: You also mentioned the importance of quality of service.
AB: We believe the best way to get quality of service is to support a model with queues. You can write intelligent tools to take things out of queues and process them in the order you need. If you simply spin up threads on machines every time a request comes in, you can't scale beyond the fixed limit of the hardware. A challenge for people on the Web has been delivering a better quality of service to a high-profile customer than a low-profile customer. They're both coming in over the same Web gateway. At the end of the day, the Web service gateways are synchronous and spin up threads immediately in computers because they're synchronized. When you have a queue in the model, you can deliver very good quality-of-service characteristics. You can see how long something is sitting there. It's harder to see if it's spun up as a thread.

Reliable messaging is also part of quality of service. The customer has to decide. Reliable messaging usually comes at a price in terms of latency, in terms of speed - customers have to make the right trade-offs.

WLDJ: You worked for Microsoft and now you're with the Java camp. Do you see a difference in the approaches they take toward Web services?
AB: I worked for Microsoft for 11 years and played a role in getting Web services off the ground. The difference is in who the customer is. In the Java camp we think a great deal about enterprise computing and so the challenges we run into almost immediately are about enterprise computing. I'd say the Java community has taken off around enterprise computing and I think that's something that people miss a lot.

The Java community thinks a great deal about Web services as an integration platform and less about Web services as a consumer story. That's starting to change. Push Java is dominant on mobile devices because mobile devices are such a natural companion to Web services, they need a message-based model. Look at RIM as a success story for applications on mobile devices. We're starting to see a natural marriage and that's driving more of a consumer focus into how the Java community thinks.

Java has huge support among the customer base. Customers like the open model. Many bet on PowerBuilder years ago because it was the best for client/server computing. It had a lot of proprietary language. These days they're frustrated because there was only one vendor, which is not always the healthiest vendor. Our customers don't want that again, they want to know the language isn't controlled by any one vendor, and that there will be choices. That's Java's strength.

Microsoft's strength is that they control the language absolutely and proprietarily. They can move quickly to extend the language and to learn from Java, and they have. We'll see if Java in turn learns from what Microsoft has been doing and continues to extend itself. If it does, Java will be the dominant language for a long time to come.

We believe people can work together - the deep, hard-core systems programmers, the gurus, and the others who basically are writing business and application logic, which is what actually added value to their company.

Most of our customers don't beat their competitors by doing better plumbing. I see these two communities - systems programmers and applications developers - that want to work together. Having Java as the unifying story between them is powerful because it means each one can easily read and expand and augment what the other does in a very seamless way. I love watching one of my developers build a Web service using WebLogic Workshop, and then one of my other developers, a "VI and emax, unless it's in the kernel I am not interested" guy, extends it to do something weird and wonderful that I'd never figure out. For us, Java is a lingua franca. The CLR model ultimately has the most value if multiple people are writing in multiple languages. Customers don't really want that. If all their developers are writing in different languages, then it's very hard to move code from one community to another.

Even if the CLR were open, and I'm a little skeptical, it's not clear that having a common language runtime per se is better.

What's interesting is how C# has learned from Java and innovated in its own way. If Java continues to extend and grow; if it learns how to natively talk to XML; if it learns how to natively add extensible metadata, and all the things that should happen; if it learns how to handle the fact that messaging is a fundamental core competency of language and that language should have constructs for rendezvousing messages, then Java will continue to be the dominant language in the enterprise, and probably on devices, because at the end of the day, mobile devices will dwarf PCs as well. On the other hand, if it doesn't, if it's declared to be perfect as is, and/or is height-bound by the fact that it's a community effort and takes more work to extend than one owned by a single very smart and aggressive vendor, then there could be risks.