Roundtable Transcript, Part 1 (Continued)

Standardization of Business Processes and Frameworks
[23:55] Renaud: To pick up on one of Mike's points actually, which I think is definitely worthwhile exploring, how do we keep Java in front of SOA and leading in that space? I think one of the key parts of the SOA development model overall is going to be around workflows: the ability to define business processes, define business workflows, and to really stay in front of that.

Now the development around the standards for this sort of thing, today, really that leadership is happening around BPEL and around the non-Java-specific standards. And just like I think we've done quite a good job of keeping up in the Java community with the number of XML standards and trying to keep those things reasonably well in sync—not always perfectly, of course, but reasonably—I think the Java community's effort to stay in sync with BPEL to be able to offer the right kind of bindings, the right kinds of tools for BPEL is going to be determining in terms of Java's position in the SOA race.

[24:58] Phipps: Now I want to bring in Ted Farrell over here, who has snuck in. Ted, do you want to carry on with SOAs, or do you think something else been a more significant element of Java development this year?

[25:10] Farrell: Yes, I guess I can comment, I tried to pick up—I apologize for being late. To just backtrack going back to the original question, I think it all sort of ties in, which is to me the value of SOA couldn't be, in my opinion, couldn't be valued as the most significant element because it's still developing, right. I mean what will make SOA powerful is the levels of standardization, which we haven't reached yet.

Michael talked about some of the Javas and JSRs, but it goes beyond that. It's the pure "I won't talk to anybody" type of standards. Is it going to be BPEL? It looks that way; a lot of people are leaning that way, but…is it going to be WSDL? I mean none of those things have really been formally defined, and until they are you won't have the kind of choice of flexibility. And then dropping down a level in the Java space then how are we as Java vendors going to take advantage of that? What can we do to sort of optimize that? Once we get to those levels of standardization, which I think we're on the verge of doing, I think then it really becomes exciting and then it becomes an overwhelming, powerful thing. But without that it's sort of a more proprietary evolution of a lot the EAI systems we've seen.

I'd have to cast my vote toward application development frameworks, which in a very short period of time have appeared and immediately added value for our customers. We have customers who weren't in this space before developing applications now, and were coding before and are enjoying a much more of a RAD, declarative type of way of building applications. I think over the last short period of time, a year or so, application development frameworks have had a bigger impact probably on application development, where SOA's impact is going to be huge, but I just don't think it's going to … [voice trails off].

[26:53] Bechauf: Frameworks are really important because the underlying complexity of the technology increases, increases, increases every year. You look at, for example, just following up with the technologies that we talked about. I mean they used to be servlets, they used to be JSPs. Now we have JSF, we have portlets. I mean all others as all fit together. I think if there are no good declaratively driven frameworks, the normal application developer is going to keep spending more and more time just trying to get some understanding of what the underlying technology means.

[27:22] Elloy: I think frameworks have tremendous value, but one thing that we risk as a set of vendors doing, and this perception to a large degree exists in the marketplace, is having frameworks obscure a lot of detail that developers need to get to make something really integrate, really perform, really hum for a company. They're phenomenal when it comes to standardizing and abstracting, but if they do that and at the same time remove the ability of the developer to go dig, then I think [that's unfortunate for vendors].

[27:50] Renaud: There's no reason why they have to do that. I think we've learned enough about frameworks today to be able to offer the right abstractions to the right customers. The right people want to be able to access to write abstractions. If those abstractions are well defined in terms of standards, then you give access to the right level of abstraction to the right people. If you need to dive deeper, if you need to go and twiddle the knobs, and set transaction parameters, and things like that you can. If you want to stay high up and get things done quickly you can.

[28:22] Milinkovich: Yeah, the acid test for me has always been, make the simple things simple and make the hard things possible.

[28:28] Farrell: Yeah, I think that's a valid concern. I think frameworks in the past have been black boxes, which just aren't acceptable today. I think there's a large group and a growing group that want to be able to get down there. Finding the balance where different levels of developers at different skill levels can all work together will be key. To me the bigger danger in frameworks is us as vendors not counting them as part of the core application server, not counting them as needing to go into the standards. And we have a standards organization, the Java Community Process, and the frameworks are no different, and we have to continue to push that technology back into those standards.

[29:02] Elloy: Frameworks are not frameworks, right? So frameworks to a tool vendor is one thing, or to a stack vendor is one thing, frameworks to a larger size are fundamentally different, so they care about a vertical framework or some horizontal framework but again at the business application level managing some ubiquitous definition of a customer, or a vendor, or XYZ, which then can be verticalized off of—that's completely [contrary] to the way all of us may think about frameworks, and both invalid. Both make the art of software development more effective.

[29:32] Chappell: I think another common theme across frameworks and their surrounding tools is the idea of configuration rather than coding. I agree with Ted that there needs to be a way for Java developers to drop into coding when they need to, but I think we've all got larger things as developers have a bigger picture to look at, and having frameworks that allow us to configure things like process flows, BPEL choreographies, and service-oriented interactions, the better off we can focus on the larger business and architectural issues.

[30:15] Phipps: Now we have one more vote to get in, which is Mike.