In-Depth

A Different End-to-End Solution

Ted Farrell addresses the challenges of SOA-based implementations.

<>Oracle's Ted Farrell, chief architect for the company's application tools division, has been expounding on the benefits of service-oriented architectures for some time. Recently he has been focusing on application development frameworks for developers who build entire applications instead of separate projects or subsystems. His keynote address at Java Pro Live! yesterday showed how to overcome the challenges inherent in building end-to-end solutions. Farrell met briefly with FTPOnline to discuss his presentation as well as SOA and other Java technologies.

Q: Your keynote at Java Pro Live! addressed the challenges that developers, managers, and architects face when implementing technologies on SOA-based architectures. Would you provide a brief overview of your topic?

Ted Farrell: There's a lot of talk and a lot of hype for service-oriented architectures. It's a new world and there are still many challenges. I covered techniques such as employing development frameworks to overcome the challenges in designing, building, implementing, and deploying enterprise applications. Frameworks provide an end-to-end solution for service-oriented architecture and service-oriented architecture development. It is a fundamentally different way to build applications. A lot of the problems that needed to be solved before are still there, but at the same time a lot of the problems that needed to be solved before sort of go away and new equivalent problems appear in the new environment.

So I wanted to take a walk through the challenges and the hurdles of service-oriented architectures, and talk about their benefits and why it is a good thing to move to them, but also to talk about this new world and how things look and the possible solutions people can take to address them.

Q: We've certainly been hearing about SOA for some time. It seems like some vendors have their arms around it, and others seem to be unclear on where it's going exactly. It's certainly a topic you've spoken and written on extensively. How is Oracle helping developers and IT professionals understand and take advantage of service-oriented architectures?

Farrell: You hit the nail on the head, I think, with the time. It's a complicated issue to solve. If you talk about the high-level concept, rather than building big monolithic applications, you're really trying to break down your functionality into these reusable services with well-defined APIs that you can then use and assemble into applications: both business applications that don't have user interfaces and user interface—human interface—parts of the application that get a lot of reuse and are a more dynamic environment.

I think the biggest benefit in services-oriented architecture is the paradigm shift from building these big monolithic applications that you generally version all at once. You version them over a long period of time—maybe every year, and often every two years—but it takes so long to coordinate all of that.

Service-oriented architectures are designed to make an environment where you are basically making smaller, continual changes, so you're tweaking a service there, adding a new interface there, and updating parts of it. Because the service-oriented interfaces are so well-defined, you're not bound; everything isn't bound together in one big hunk, so you have more flexibility in being able to change the app to the business environment or the market, as well as being able to evolve the app faster to customer needs. I think that we've been doing this a long time, and there are a lot of pieces to it. Companies the size of Oracle have the breadth of products; not only do we have a solution and an answer in everything top to bottom in the SOA stack, but we also appreciate and embrace the standards and the things that have got us here.

Any of those pieces can be switched out for third-party solutions, too. We realize that a lot of companies have a heterogeneous environment and need to plug things in. Basically, we go through and educate our customers on taking what they have and trying to get it into this environment. It's not something where a company makes a decision overnight and says, "we're going to SOA," and everyone starts rewriting the next morning. It's much more about appreciating what the advantages of the architecture are, evaluating the architecture for where you can start, and then taking the functionality you have and building these interfaces on top of them. Rather than rewriting them, you expose them in a different manner so you can start using them in new applications. Basically, it's a migration of the current architecture to the new one.

Most of our customers to date, except for the ones who are lucky and either started a long time ago or got to write something from scratch, are in a mixed world where some of this stuff is still tied together pretty tightly, but still has some well-defined service interfaces on top of it. That functionality is being used either by them in different ways or by partners they didn't have before because they couldn't get access to that information.

Q: As the technology evolves, how would you describe the role of the Java platform in this evolution, and, specifically, do the development frameworks for these complex enterprise-level workflows mean a healthy future for Java and the professionals—developers, managers, and architects—who develop with it and deploy those enterprise applications?

Farrell: You know the nice thing about service-oriented architectures is that the client doesn't have to necessarily worry about the implementation. They have a service, and they talk to the service, and it does a function for them, and all they really care about is that they get the right data back and they get it back in a fast enough period of time.

But on the other side, the provider side, the implementation platform for SOAs is critical. It's the thing you're building your business off of—it's what you're betting your business off of—and that's where Java, J2EE, really shines. It's an incredibly mature, robust platform. It has been for years. There's tens of thousands of enterprise applications running on this architecture today, so it really gives you the firm foundation for building these things. I think those skill sets are definitely going to still be needed. In picking that architecture—and I think that's a popular architecture to pick—just to build it out, and have it all running and then the interfaces, of course, you expose them so other non-Java clients can take advantage of them as well.

You know one interesting thing, and one I gave a talk about at JavaOne last year, is the question of, "which is better, J2EE or .NET?" Initially there were a lot of technical battles back and forth, and every time someone came up with something the other side countered with something equivalent. It really is hard. I think it comes down to the type of application and the type of developers for which one is most appropriate. At the end of the day, what you have in J2EE and its strength has always been the community around it, so you have pretty much every single software vendor in the world (except for one) committed to it and building applications on that.

And what that means to the end user is that at the end of the day, services are fine. They serve a great purpose; I can now talk to something that I might not have been able to talk to before. Web services also have overhead associated with them, and they are just one example of a service-oriented interface. SOAs aren't just about Web services. I think a lot of people tie those two things together exclusively, but if I have a system and I'm talking to different systems, I basically say, "OK, I'll send off a Web service request and actually get that back."

What we're able to do with some technologies such as the Web Services Invocation Framework (WSIF) is to send more information about the protocols. So I can send a request to a server, and ask it, "Hey, are you a same type as me?" So if I'm Java, if I'm J2EE, I can say, "hey, are you J2EE?" and we can have a native conversation without the programmer even getting involved. And if you're not J2EE, you know what? I can still talk through Web services as well.

It gives us strictly an opportunity to try to optimize the communication and the data exchange between the two systems. With so many vendors supporting J2EE, the chances of your system talking to another J2EE system are much higher than if it's a .NET or another type of system. So there's a benefit there in both the robustness and the scalability of the platform, as well as the breadth of the platform and how many installations there are.

Q: Java Platform, Enterprise Edition 5 is slated for a first-quarter release next year. Do you have an opinion about the release and the technology enhancements that it's reported to deliver, and do you think it will simplify development as JSR 244 purports it to do?

Farrell: One of the main features is the new EJB 3.0. That's going to make a big difference as far as developer productivity, usability, and approachability to that platform. I think container management with persisted objects has always been an interesting concept, but one that a lot of people shy away from when they see some of the overhead to it. One of the nice things about EJB 3.0 is that it takes away from that—it takes the hurdles away—so it ends up being a more approachable system.

JSR 181, which is the Web services metadata, had a lot of potential, but I don't know how widely used it is. JAXB 2.0 and JAX-WF, which is the next generation of JAX-RPC, are there too.

Then there's JavaServer Faces, which Oracle is a big supporter of, and we think it's going to make a huge difference in the overall platform. It standardizes the way user interfaces are built and separates what we have today. Today the UI component and the way they render are tightly bound together, and I think that causes a lot of problems for people trying to build applications. With JavaServer Faces they have separated the components in the component model from the way they render, and we've taken advantage of that and were able to provide a single programming model to our developers. Using these different render kits, we were able to support a wide variety of platforms without the developers having to worry about it.

So we do the standard browser interface, as well as mobile devices, as well as Telnet devices, and the programmer doesn't have to worry about any of that stuff. They're just programming standard JavaServer Faces and JSPs, and the render kits take care of all the device-specific technologies that [developers] normally would have to learn and program in themselves.

Q: Doesn't that tie into your involvement in the standard data binding and data access facility in J2EE for the JCP, in which you focus on declarative bindings and data controls as the core standard framework allowing the interfaces that expose loosely coupled services to be bound to back-end business logic?

Farrell: Right. Yes, that's a whole JSR that we're leading: JSR 227. It's almost ready for public review; we're trying to get that out this year. Even if you have gone to the effort of building these back-end services, there's still a lot of code being written to use those services and user interfaces. [JSR] 227 allows us to do that declaratively and, if you have a design time, visually as well. That makes the burden of building user interfaces on top of these services much easier. A lot of time talking about SOA is spent on Web services and business processes, and people neglect the other side, which is: You have to have some kind of user interface involved in your application.

FTPOnline: Will Java EE 5 will include that standard?

Farrell: It depends on when it comes out. It's a timing issue. We're going to try to get it out and try and get it in there. Either way, it will be an add-on if it doesn't get into the core of version 5. That's the way JavaServer Faces works too. They came out in mid-release, and they're sort of supported on 1.4 today, but it'll be a first-class citizen in Java, J2EE 5.0.
Most   Popular