In-Depth
QA: Manes on mighty morphing services
Middleware expert Anne Thomas Manes has graced these pages before, most recently with an excerpt from her book A Web services guide. We caught up with her just before she held a webinar on the dynamic state of Web services platforms.
Q: You’ve talked a bit about the mighty morphing platform. What is that?
A: The concept of the mighty morphing platform is that the nature of Web services platforms is dramatically different, and is in the midst of massive change compared to what it was just a couple of years ago. One example is all the stuff Microsoft is now about to put into the Windows platform when they release Longhorn. Instead of just having a programming language, and class libraries and the occasional framework, at this point a platform now is an application server, a portal server, an integration server, Web services technology, database systems, and all these other things that are all coming together into a single development platform.
Q: Will Web services blend into the talk about app server platforms?
A: Web services is becoming a core piece of every app platform that’s out there. .NET is all about Web services and in J2EE 1.4, Web services is an integral part of the platform. We’re also seeing that off-the-shelf apps -- things like PeopleSoft and SAP and the Oracle apps -- are coming with Web services built into them. Web services is just driving itself deep into the IT fabric. You’re not necessarily going to have to go out and build a separate Web services technology anymore, because Web services will be part of your platform.
Q: Compared to the days of CORBA, would you say that a developer and/or an architect’s job is easier?
A: The goal of these technologies is to reduce the amount of ugly code that developers have to write. That does not mean that these high-end developers have to worry about whether or not they’ve still got work to do, because you’re never going to get to the point where it’s totally automatic. There’s still going to have to be some hard-core developers doing some interesting work. But I think we’re going to wind up implementing more of our intellectual property in models, and then we can let the models generate the real code for us.
You don’t want to be developing a lot of code that’s bound to a specific platform because that platform is going to go away in anywhere from two to five years, and you don’t want to have to go back and rewrite your code to take advantage of a new level of an operating system, or a new level of a framework. If you can regenerate your code from your model and have it automatically take advantage of the new capabilities of the platform, that’s a wonderful thing.
Q: Do these models include business process models?
A: I think that the modeling technology is a whole lot better now than it was even just two years ago, but there’s a limit to how much automation you can do when you’re talking about extremely complex business processes.
Q: Have you uncovered new rules or guides for Web services app building in recent months?
A: The goal is to build applications that are service-oriented in nature. You want to make sure that they’re very document-oriented. You don’t necessarily want to expose the object model of your service to the potential clients out there. You have to remember that Visual Basic applications don’t deal well with Java hash maps, so you don’t want to expose a Java hash map through your WSDL interface.
We’ve certainly learned a little more about what are the right ways to design services since we’ve started experimenting and playing and trying to deploy real systems. Things to be concerned about when designing applications: Make sure that the interface you expose is completely platform-neutral. Try to make your interfaces chunky vs. chatty. You want to reduce the granularity of the interface so that you’re not passing gazillions of messages back and forth. Best practice is to actually start with the WSDL definition and generate code from the WSDL rather than trying to start with a Java object or a .NET object or something like that and then generate your WSDL from that.
Q: Is federation like the kind of stuff that was talked about with databases or with DB2 in recent years or is it something else?
A: Federation is all about making things talk to other things and basically reaching outside of your domain and then trying to bridge the two domains. We want to establish a trust relationship such that I can send you information about an identity, and you’ll accept from me that this is a validated identity and grant them access to your services without forcing a specific authentication within your own environment. When you’re talking about federation of other services, it’s like I have a queuing system over there and a queuing system over here, and now I have to somehow bridge those two together. If I want to federate transaction systems, you have a transaction management coordination system there, and I’ve got a coordination system here, and how do we coordinate a transaction that spans both of these environments? It’s the same problem we had when we were trying to federate database systems, but we’re just trying to do it in all aspects of distributed computing and that’s where it gets tricky.
Q: Are we still in the early stages of even just exploring that?
A: We’re still pretty early. Right now the primary area of federation that we’re working on is in terms of federated security. And certainly Microsoft has proposed WS-Federation, Microsoft and IBM. Meanwhile there’s the entire Liberty Alliance Project which is also focused on making federation a reality, and that’s actually a little farther along than the IBM-Microsoft effort. But I would say we still have quite a ways to go before any of these things will be ready.
Q: Do you see application development managers and programmers/developers starting to learn about this?
A: In the long run, we’re going to have a set of policies; we’re going to have a new classification of developer within an organization whose role is to manage policy. And basically [they will] establish policies for all these operational semantics, things like security, reliability and transactions, and rather than hard-coding this stuff into application code, what [they will] do is to define the semantics of a given application or a given composite application using these policies and then the runtime system will enforce those policies.
Q: What’s the state of tools for Web services? Is it still finding the specification, and then starting to code by hand?
A: I don’t know too many people who actually code Web services by hand. Nobody writes their own WSDL files by hand anymore.
Q: Is there trouble when they get WSDL files generated by some tool that they may not totally understand or anticipate its behavior?
A: We still have some significant issues with some of those things, but I think that within the next year or two most of those issues are going to go away. Another aspect of the mighty morphing platform is that more and more code is getting pushed down into the bowels of the platform, so that developers don’t have to write as much. When you start using managed code environments like Java and C#, you don’t have to write garbage collection code anymore. You don’t have to write memory management code anymore. That’s all part of the basic platform. But as you start doing distributed computing, you don’t want to have to write your own session management stuff. All that becomes part of the platform. As Web services technology matures, you’re going to get to the point where developers never have to play with WSDL at all. It’s all just done under the covers. You say, “That’s the service I want. Generate me all the code I need in order to talk to that service.” And everything gets done automatically; all you have to do is write the business logic and not write any of this messy, ugly plumbing code underneath.