Business
Tooling for Web Services
As Web services emerge as the next tour de force in software development, Builder.com had a conversation with iPlanet CTO Hal Stern on the tools that will be available from Sun to help developers meet new design challenges presented by the Web services market.
As Web services emerge as the next tour de force in software development,
Builder.com had a conversation with iPlanet CTO Hal Stern on the tools that will
be available from Sun to help developers meet new design challenges presented by
the Web services market.
Development tools for WSDL and UDDI
Builder.com: What testing and debugging tools does Sun provide for developers and architects looking to implement Sun ONE, Sun’s open net environment?
Stern: There are two answers to this question. First, through our Forte Tools Division, we have an integrated yet extensible tool set that covers the whole IDE spectrum that will generate Java Server Pages and Enterprise Java Beans. We are also working with a couple of partners to add the UDDI [Universal Description, Discovery, and Integration] and WSDL [Web Services Description Language] hooks. The tools are in place today for the practical implementation of Web services. Our roadmap over the next couple of months is to continue to roll out WSDL and UDDI generation tools.
I think that the critical point here is the Forte framework because there is a facility in it called NetBeans, which is essentially an open source framework that we encourage people to extend the development environment by adding other pieces of functionality. I have seen people who have added UML-level modeling tools.
The second answer is that companies like WebGain, BEA, and Borland offer tools for the Java environment.
One of the things that we have been doing is focusing on Forte tools what we have in Java development, such as thread-aware debuggers and tools that are able to map Java classes to the runtime environment and match them up with the higher level tools that provide the wrapper functions that generate WSDL, UDDI, and SOAP calls.
One of the problems that we are looking at as we do testing, debugging, and development, is not only getting the application to compile and deploy correctly, but once it is deployed how do you observe it or add the interface for observability so it can be a part of a well-managed runtime environment? This point will become more critical over time, especially in terms of dynamic replacement—and you tell the application what to replace or "Stop and replace this interface."
Building applications in a changing environment
Builder.com: What architectural paradigm shifts are involved in designing J2EE-based Web services?
Stern: I see six paradigm shifts. These are in no particular order.
The first involves deploying applications or services. The finer grain by which you solve the problem means you have more interactions. For example, a monolithic application probably has a simple API—data in and out. If you now model that same application as a series of five or 10 Web services, you now have 10 interactions to worry about and possibly 10 interactions with 10 other services, so now you are up to 100 interactions to worry about. And, obviously the problem gets exponentially larger very quickly. So, you are now worried about how to get data from one place to another and ensure consistency about its meaning. The emphasis on XML and XSLT will help with this issue. There are some good tools out there to do the mapping and modeling.
The matching of time domains is even more important. You may have systems out there that are batch-oriented and now you want to hook them up to a Web services interface. The Web services interfaces are working in real-time or near real-time scale. Obviously, there is a lot of work being done in asynchronous, long-running transactions, but you will have to bridge the multiple time domains that you are working in. As you address the practical problems of deploying applications, some key questions must be answered. Those questions include:
Builder.com: What are the other paradigm shifts?
Stern: The next paradigm shift is the approach to security. If you come in through an application’s APIs, you have to deal with whatever authentication mechanisms that it has in place. If you find a way to communicate with the application in functional, Web-services pieces, then the key question is: How do you establish the context or the business rules that may exist outside the application? Do you want those business rules to be consistent with access to other pieces of data?
I categorize the next two shifts as “things to be aware of.” One is that we are moving towards a world of real-time delivery. There may be many Web services that have different functional components that interact over a very long time frame, but as soon as you involve the end user, it becomes a real-time problem. The IT industry has to become much better in real-time application development. There’s a school of thought in computer science that deals with real-time issues, such as where caching occurs, how you do event processing where you bound transactions to guarantee that things recover quickly, as well. This is not a factor only for the guys who write code for nuclear power plants or microcontrollers. It has become a mainstream discipline.
The next [change] is the change in a porting relationship. When you start to talk about Web services, from [Sun ONE’s] perspective, it changes the nature of a porting relationship. I think this is very important because a lot of people come to Sun and say that you have iPlanet and other products, but yet you go out and do business with BEA and Vignette. Why? The answer is our partners touch the Sun ONE software stack in a variety of ways. We are now looking at porting as how your application or technology interacts with the various pieces of the Sun ONE stack—from directory and identity systems to portal for delivery to Web and application servers for basic service containers to integration servers for talking to existing systems. Different software vendors may talk to all of them or only to one of them so there’s no requirement that you go rewrite everything in Java. It is more an architectural question of how you interact.
This leads me to the last two [paradigm shifts]. The first is the problem of application factoring. In other words, what [applications] run on the client and what [applications] run on the server. James Gosling [Java architect and Sun vice president] put this very well in an interview a couple of weeks ago. He said, “I have blood on my right arm. I have blood on my left arm. Which one is more important?” This is a very good way to look at the problem. It is not that we are saying J2EE is expensive [in terms of operational overhead] for the standard edition or the microedition for what would go into the handset; it is a question of figuring what you need to do in the client and where you need to establish control and persistence on the server side and how you are going to do the data and transaction management to make [the application] work. We are coming out of a world of very flat clients to a world where a lot more functionality is being managed on the server side because it has better control, it’s better scaled, and is more secure. This requires that we think carefully about the application. For example, if this means that you have to move large amounts of data back and forth, the application may run fine on a LAN but may not run so well when you are over the VPN in India or may not run at all if you are accessing via your Palm over a wireless network.
Finally, the final paradigm shift driving this comes from a very high level The business needs drive the interest in Web services, as opposed to implementing an interesting technology that is going to solve a particular business problem. So first identify specific business needs and use those to drive some of the Web services push.
Development tools for WSDL and UDDI
Builder.com: What testing and debugging tools does Sun provide for developers and architects looking to implement Sun ONE, Sun’s open net environment?
Stern: There are two answers to this question. First, through our Forte Tools Division, we have an integrated yet extensible tool set that covers the whole IDE spectrum that will generate Java Server Pages and Enterprise Java Beans. We are also working with a couple of partners to add the UDDI [Universal Description, Discovery, and Integration] and WSDL [Web Services Description Language] hooks. The tools are in place today for the practical implementation of Web services. Our roadmap over the next couple of months is to continue to roll out WSDL and UDDI generation tools.
I think that the critical point here is the Forte framework because there is a facility in it called NetBeans, which is essentially an open source framework that we encourage people to extend the development environment by adding other pieces of functionality. I have seen people who have added UML-level modeling tools.
The second answer is that companies like WebGain, BEA, and Borland offer tools for the Java environment.
One of the things that we have been doing is focusing on Forte tools what we have in Java development, such as thread-aware debuggers and tools that are able to map Java classes to the runtime environment and match them up with the higher level tools that provide the wrapper functions that generate WSDL, UDDI, and SOAP calls.
One of the problems that we are looking at as we do testing, debugging, and development, is not only getting the application to compile and deploy correctly, but once it is deployed how do you observe it or add the interface for observability so it can be a part of a well-managed runtime environment? This point will become more critical over time, especially in terms of dynamic replacement—and you tell the application what to replace or "Stop and replace this interface."
Building applications in a changing environment
Builder.com: What architectural paradigm shifts are involved in designing J2EE-based Web services?
Stern: I see six paradigm shifts. These are in no particular order.
The first involves deploying applications or services. The finer grain by which you solve the problem means you have more interactions. For example, a monolithic application probably has a simple API—data in and out. If you now model that same application as a series of five or 10 Web services, you now have 10 interactions to worry about and possibly 10 interactions with 10 other services, so now you are up to 100 interactions to worry about. And, obviously the problem gets exponentially larger very quickly. So, you are now worried about how to get data from one place to another and ensure consistency about its meaning. The emphasis on XML and XSLT will help with this issue. There are some good tools out there to do the mapping and modeling.
The matching of time domains is even more important. You may have systems out there that are batch-oriented and now you want to hook them up to a Web services interface. The Web services interfaces are working in real-time or near real-time scale. Obviously, there is a lot of work being done in asynchronous, long-running transactions, but you will have to bridge the multiple time domains that you are working in. As you address the practical problems of deploying applications, some key questions must be answered. Those questions include:
- Where do I cache?
- Where do I do my replication?
- When do I store my data in my network so I can get the response times that I am looking for?
Builder.com: What are the other paradigm shifts?
Stern: The next paradigm shift is the approach to security. If you come in through an application’s APIs, you have to deal with whatever authentication mechanisms that it has in place. If you find a way to communicate with the application in functional, Web-services pieces, then the key question is: How do you establish the context or the business rules that may exist outside the application? Do you want those business rules to be consistent with access to other pieces of data?
I categorize the next two shifts as “things to be aware of.” One is that we are moving towards a world of real-time delivery. There may be many Web services that have different functional components that interact over a very long time frame, but as soon as you involve the end user, it becomes a real-time problem. The IT industry has to become much better in real-time application development. There’s a school of thought in computer science that deals with real-time issues, such as where caching occurs, how you do event processing where you bound transactions to guarantee that things recover quickly, as well. This is not a factor only for the guys who write code for nuclear power plants or microcontrollers. It has become a mainstream discipline.
The next [change] is the change in a porting relationship. When you start to talk about Web services, from [Sun ONE’s] perspective, it changes the nature of a porting relationship. I think this is very important because a lot of people come to Sun and say that you have iPlanet and other products, but yet you go out and do business with BEA and Vignette. Why? The answer is our partners touch the Sun ONE software stack in a variety of ways. We are now looking at porting as how your application or technology interacts with the various pieces of the Sun ONE stack—from directory and identity systems to portal for delivery to Web and application servers for basic service containers to integration servers for talking to existing systems. Different software vendors may talk to all of them or only to one of them so there’s no requirement that you go rewrite everything in Java. It is more an architectural question of how you interact.
This leads me to the last two [paradigm shifts]. The first is the problem of application factoring. In other words, what [applications] run on the client and what [applications] run on the server. James Gosling [Java architect and Sun vice president] put this very well in an interview a couple of weeks ago. He said, “I have blood on my right arm. I have blood on my left arm. Which one is more important?” This is a very good way to look at the problem. It is not that we are saying J2EE is expensive [in terms of operational overhead] for the standard edition or the microedition for what would go into the handset; it is a question of figuring what you need to do in the client and where you need to establish control and persistence on the server side and how you are going to do the data and transaction management to make [the application] work. We are coming out of a world of very flat clients to a world where a lot more functionality is being managed on the server side because it has better control, it’s better scaled, and is more secure. This requires that we think carefully about the application. For example, if this means that you have to move large amounts of data back and forth, the application may run fine on a LAN but may not run so well when you are over the VPN in India or may not run at all if you are accessing via your Palm over a wireless network.
Finally, the final paradigm shift driving this comes from a very high level The business needs drive the interest in Web services, as opposed to implementing an interesting technology that is going to solve a particular business problem. So first identify specific business needs and use those to drive some of the Web services push.