Roundtable Transcript, Part 1 (Continued)

Ecosystem Interaction
[14:03] Phipps: So now I'd like to see if we have some other most important contributions. Jeff, I don't think you've said anything yet.

[14:15] Cobb: As far as the most important contribution to Java or to tools?

[14:15] Phipps: To tools to the development of Java applications.

[14:20] Cobb: The tools to the development of apps overall, I would say, I vote with the SOA people. It feels like it's turning from above board into something that's really happening, where the weight of that starts to feel more concrete now. It used to be you focused a lot more time and energy on getting the thing right on the early part, the sort of front end of the supply chain, the development cycle. Right? And what the SOA causes is much more pressure on the interaction of the thing once it's built interacting with the rest of the world, the rest of the ecosystem. I think that's the thing that's going to change the tools, that's going to change the development process, that's going to change the management process as Java keeps advancing.

[15:27] Elloy: Management process is absolutely critical for a true SOA. So you don't have control over these Web services, but yet you're relying on them. So what do you do? What's your fallback plan? How do you [reach] your uptime?

[15:42] Chappell: I'll agree that as the runtime environments migrate more toward a loose coupling between services and applications, the tools need to migrate to be able to support that type of interaction.

[15:55] Burba: Right. It's very much the difference between a sealed environment that you can control and debug, like tuning up my car versus taking the thing out on the highway and trusting that everybody else is driving on the right side of the road. The nature of the tools and the nature of the problems that you need to be able to handle change pretty significantly.

[16:13] Chappell: Right, and I would even say that next year's challenge would be for all of the tools vendors here to recognize—oh, was I running through your next question of what's next year's challenges? [chuckles]—that Java developers need to understand that there's more than just Java that you need to work with in the environment, so the tools that deal with loosely coupled services in an SOA need to understand that, they have to bridge that gap of how those things fit together.

[16:45] Stover: I would say that many of us in the tool community realize that. But the problem is that we talk about process. So does the average Java developer know that? And the answer to that unfortunately is most times no, because what I was going to say is while SOA may make the tools community want to think a certain way, does it make us think a different way from requirements? Does it make us think that we need to do certain things in development that we didn't do before with a traditional application?

[17:04] Chappell: Well, yeah because…

[17:05] Phipps: It absolutely does.

[17:06] Stover: Right, so, but coming to that…

[17:09] Elloy: The reason why is that first of all you need to leverage what's out there right, so how do you know what is out there? Then how do you map that against what is out there? Does it really make money, or is the object just called the same thing? Getting customers to just call it the same thing is fundamentally different.

[17:24] Chappell: Well the real question is, are the developers building the "S" or are they building the "A"? And what is the tool really geared at?

[17:32] Phipps: That's my biggest worry about all this discussion about SOA is that I'm hearing plenty about the "S" (there's quite little of "O" going on [laughter]) but the "A" seems to vary from person to person, and that makes me worry that we're going to end up with a world where interoperations and exercise are left for the reader rather than a world where the interoperability is built in from the ground up.

[17:54] Stover: Well, unfortunately, we always learn the hard way, right?

[17:56] Phipps: You would think they would have learned by now.

[17:58] Stover: Well, I mean, we attempt to, once we, for those of us in this room, we've all done at least one thing wrong. And then we try not to do that again because it hurts so much. But unfortunately that's the way we learn in this environment. It's our job to help the Java community recognize that those things are there to hopefully help them avoid the pain of getting burned with something like, that's a problem or performance problem.