Borland's SOA Push -- JBuilder 2005 and Beyond
Learn how Borland's JBuilder 2005's Web Services Designer, shipping next month, is only the first step in Borland's plan to assist Java/J2EE developers "bridge the gap" between Java/J2EE and SOA skills. Integration Developer News spoke with Borland's chief scientist for developer tools Rick Nadler to learn more about WSD and Borland's future SOA tools.
IDN Executive Overview
Among topics covered in this interview are:
by Vance McCarthy
Borland's JBuilder 2005's Web Services Designer (WSD) is only the first step in Borland's plan to assist Java/J2EE developers "bridge the gap" between traditional Java- (container-) centric skills and the promising, new world of Service-Oriented Architectures (SOAs).
To get insights into Borland's latest WSD technology, shipping in September, as well as Borland's longer-term plans for helping architects/developers with their SOA plans, Integration Developer News spoke with Borland's chief scientist for developer tools Rick Nadler.
An Integration Developer News
Interview with Rick Nadler,
Chief Scientist for Developer Tools, Borland
IDN: Can you briefly describe the WSE approach in JBuilder 2005?
Nadler: In JBuilder 2005, either at the server or client level, a developer could enable the Web Services Designer, That provides a developer a two-way design surface for a project that allows you to take any artifact in your project, be it a Java Bean or a Session Bean, and the [design] surface acts as a web service [manager] and keeps track of what you surfaced in your project as a web service.
The Dev Skills Checklist
IDN: You talk about "surfacing" a web service. Would this be automatic to developers, or intuitive to them? What types of skills or knowledge does a dev need to really benefit from these features?
Nadler: I think you will need some domain knowledge about what's in your server. If you just blindly surface everything you may not be optimizing your architecture.
IDN: What's your best advice for the types of places where Java/J2EE developers could begin implementing SOA/web services? Is there a "common type" of Java application that is well-suited to web-servicizing?
Nadler: The entire industry is trying to figure out just what kind of role SOA will play in the enterprise. For now, the best recommendation is stay "coarse-grained" and "non-chatty." So, for example, if you have an interface that needs 1,000 method calls per second, for example, or it needs a great deal of state [management] and has very fine-grained communication -- those are not good SOA targets.
On the other hand, if you are sending a document type that needs just a little updating, and will be sent back and forth for some simple resolution, well that's a great SOA target. And, there's nothing wrong with synchronous versus asynchronous, per se. Both can work. But, you might want to worry about a situation where you can get disconnected [because] you can't serialized a state.
IDN: Many vendors offer automated tools for surfacing web services or auto-generating them. But, these tools don't often give architects or develoeprs any insight into proper design. What's Borland's take on this approach?
Nadler: I agree, that's good insight. A lot of times you may have made a mistake earlier in your J2EE design process, such as making a major APIs too fine-grained and so [these APIs] may need extra wrapping to make them into a good service in a SOA architecture.
Also, there is a fundamental difference between looking at an architecture that is tightly-bound into one programming model, versus an architecture that spans multiple programming models. And, one of the key differences is the greater reliance on message orientation and a common type system.
One SOA Key is 'Message Flows'
IDN: So, what kind of assistance or guidance does Borland's WSE provide to Java/J2EE developers that may know a lot about writing Java/J2EE for a container but not as much about "web servicizing" their work?
Nadler: First, the Web Service Designer helps developers to centralize the view of what's being consumed as a web service and what's being exported as a web service -- at the client, the server or both at the same time [WSD} also makes you start thinking of your architecture as a message flow architecture, which is very important.
IDN: What is so important about message flows?
Nadler: It's so an [architect or developer] starts thinking in terms of adding additional processors, and logic as message processors. Rather than making a call to a Java class or a method, [with a message flow perspective] you start thinking of how to add logging as a message process that can intercept the incoming message before it gets de-serialized to the business logic, or, as another example, an outbound message after it has gotten marshaled out. In other words, you need a 'message chain' view of the situation.
IDN: Sounds like message flows could be a little difficult to get a handle on at first. Do you offer a graphical view to help architects or developers get the hang of it?
Nadler: We provide a graphical console where developers see all the handlers that they added in the message flow of the J2EE container, and they also see all the available message handlers they have. So, if a developer wanted to add a log handler he can just drag it on to all the business logic endpoints that he wants and insert it into the message flow as it comes into the container.
IDN: And, how would you say this message-flow approach differs from developing with traditional Java classes or methods?
Nadler: I think it's more flexible, and in some sense a bit more like Aspect Orientation (AO) in that you're interweaving a concept into pre-existing logic. In other words, you're not designing every method with the notion that it might have to have a pre-imposed condition, but rather have a concept weaved into it later on.
WSD Hands-On: In the "Real World"
IDN: So, put the WSD into a real-world context for me. How do you see Java/J2EE developers beginning to explore building SOA-enabled assets, as opposed to regular classes or methods?
Nadler: What we're doing with WSD is encouraging Java/J2EE developers to think of exposing their business logic as a service, and exposing the methods of those services in a more coarse-grained approach.
Also, with WSD the developer will have a more "document-centric view" of the universe. Once we take that step, we're then encouraging developers to be aware that from within the J2EE container they should think of the processing as being more "messaging-oriented." That means it's easier to interweave system level processors and corporate level processors such as logging, auditing, security and the such.
IDN: So, how should developers begin using WSD? Would they start building web services from scratch, or would they add web services capabilities to existing code?
Nadler: From a usability perspective, we would expect them to add the WSD functionality to a project. This would give them the option of refreshing what's exposed as they add it. So, as they add Session Beans, for example, they can choose whether those will get automatically exported as a web service.
But, they can turn off this functionality as well. We wouldn't normally [have the tool ask the developer] 'Do you want to create this as a web service,' as soon as he's created a Session Bean. That approach would just make for a more cumbersome GUI for the end user, making him say "no, no, no" or "yes, yes, yes" after creating each element. So, WSD also has a global setting.
IDN: How much do you automate the servicizing of Java assets for develoeprs that are new to SOA/web services?
Nadler: [In JBuilder 2005], once you have made a particular server project web service-enabled, as you add Session Beans they are automatically surfaced, and you can turn that off if you don't want that to happen. But, today, we have nothing to explicitly point out poor coding [for SOA].
IDN: How does JBuilder 2005 help architects or developers get a handle on this "message-flow" view of development?
Nadler: At one level we force you to look at the [J2EE'] container's implementation of SOA as a sequence of message processors. We show you that graphical view of all the handlers you have. We also allow you to surface JMS queues and message- driven beans as web services, so to begin with you have a programming paradigm for how those [resources] will be surfaced as a web service and how you will deal with it.
IDN: Would you consider JBuilder 2005 the first iteration of Borland's web services constructs?
Nadler: To be frank, I would think of [JBuilder 2005] as the 5th iteration as we started in JBuilder 6 (laughs).
But seriously, we're continuing to raise the level of abstraction and centralize the [application] design surface. Our goal is that anyone can come into a [web services/SOA] project and understand how a particular silo consumes or exposes itself to other silos.
New Debugging, Refactoring for SOA
IDN: What about debugging? How does Borland see a developer debugging an SOA/web services project in JBuilder 2005 -- when all the operations a piece of code (or service) might do are not local?
Nadler: There are indeed new debugging paradigms that come with SOA. We are beginning to articulate them in JBuilder 2005 with what we call "customized debugger views." But, a developer still has to set the breakpoint on a Java artifact.
Right now, we don't have anything specific as far as SOA style guidelines or patterns-based guidance, butâ€¦or the future, we're working on providing the ability to insert debugging handlers in the message flow. So, with these, a developer would be able to say, "I don't know what's going wrong with this process, but when I receive a data packet that has this customer stop and let me examine it, modify it and send it on its way.
IDN: How does that debugging technology work in JBuilder 2005?
Nadler: We have a debugger that has extensible views, so that you can have a viewer of an XML doc, which is what all these messages are. But, rather than inspecting at the Java binding level or code level, you can inspect something at the XML document level. I'm talking about a fairly low-level debugging here.
But, in an [fully-enabled] SOA architecture you'll be moving into the world where you're not inspecting language artifacts or setting breakpoints on conditions within the language object instances. Instead, you're setting breakpoints and inspecting XML documents through the system.
IDN: What about refactoring? Borland has received high marks for its Java/J2EE-based refactoring in JBuilder. Is there any application of refactoring in SOA/web services?
Nadler: In JBuilder 2005, we do refactor XML and Java if there are references between the two. That's a very low-level implementation of the way J2EE container is implemented for SOA. So, we're just refactoring deployment descriptors, which are XML documents, but they have references to Java classes within them. So, [with our current refactoring], if you rename the Java class we'll rename it in the deployment descriptors.
IDN: So, do you see refactoring as an important feature that could be used by architects/developers to optimize their current Java/J2EE resources for SOA/web services
Nadler: Yes we do. In fact, [in JBuilder 2005], we have laid some important groundwork for that in two key systems.
First, in our distributed refactoring engine, which is how our refactoring of the deployment descriptor works, across tight system so if you refactor the name or the shape of something in Java you can change the name/shape of it in something else like XML schema.
Second, we offer "Distributed Refactoring" or "Team Refactoring" where we can send a message inside an artifact (JAR file, EAR file, etc.), 'I have refactored this object.' When the receiving developer or team member opens the project file they can then see everything that has been refactored, and then can apply [any necessary] refactoring then and there. This is done via an XML descriptor that describes the changes that have been made to an artifact such as "I have renamed this," or "I have added a parameter for that."
IDN: Speaking of XML, does Borland have a view about how much XML a Java/J2EE developer should know. Do you have any preferred approaches in JBuilder 2005?
Nadler: In our tools, we're enabling both scenarios to play out. Your point about introducing developers to SOA Best Practices and patterns we think will bring more people into the XML tent. But, we also need to expand the audience that can build SOA. So, it's OK with us whether you want to use [abstractions] 100% of the time, or 2% of the time. We think it should be left to the development teams to decide.
That said, I would recommend developers look close at XML Schema., the description language. In a lot of situations with SOA, XML Schema is going to be the primary design document [for development]. It won't be a language-type system.
You wouldn't be designing Java classes, you would be designing XML schema, and the two systems don't have the exact same capabilities. If you completely ignored XML Schema you'd be missing out on an important skill set. Your primary design language can be UML, XML, Java, .NET, C#, it just depends on where you're approaching it. If your goal is to work with SOA architecture, XML schema is going to be a very important design surface.
IDN: What other features will Borland be working on to make SOA/web services development and deployment easier for Java/J2EE architects and developers?
Nadler: In the future you might expect [several improvements]:
1. We're looking at doing more work on web service/SOA audit tools. Today, in JBuilder 2005, while we have audits that check for various accounting styles, and added plug-ins to check for security styles, we don't have any automatic audits for dealing with how to tell a developer to build more coarse-grained [code].
So, internally, we're thinking we might want to add audits, or guidance, that would scan code to tell the developer, "You can service this as a web service if you want, but be aware that you have 17 parameters in your method call. So, web servicing this may not be the wisest way of doing it."
2. We're also thinking more about improving message-oriented debugging. We're moving toward an "extensible debugger view " for developers. And that's because once you move to SOA you're not necessarily going to want to set break points at lines of Java code, you're going to want to set break points at this message arriving with these characteristics; and
3. We are working closely with other vendors and The Middleware Company in developing SOA Blueprints.