 | |
During my seven years at Sun, I've contributed to the various Java SE, Java EE, and Java Web Services Developer Pack releases. I hold a B.S. in electronics and an M.S. in computer science, both from Delhi University, India. I own a patent related to XML technology and have three patents pending. java.sun.com (JSC): What is your biggest challenge in writing software? Gupta: I like what Bill Joy said in Fortune: "The hardest part isn't inventing the solution but figuring out how to get people to adopt it." I truly believe that. I might evolve a good concept, but I need to explain it to people in a simple and usable manner so that it makes sense to them. I'm currently working on JSR 261 (JAX-WSA). The biggest challenge is evangelizing it correctly and getting it adopted by the developer community. The easy part is designing the APIs and writing the implementation that supports them. JSC: Is there an intellectual discipline or fun activity that you feel makes you a better developer? Gupta: I'm a running freak, and when running, I'm away from cell phones and email. That's when I'm most productive. Running helps me structure my thoughts. I recommend it to all developers, if possible. The Process of Writing Code
JSC: Can you describe the process of writing code? Gupta: I strongly believe that designing is the first and most important step in writing any piece of code. Depending upon the size of the project, I prepare an optional one-pager describing the top-level requirements of the project. That one-pager is then converted into class and sequence diagrams using either a UML (Unified Modeling Language) modeling tool or annotations in the Javadoc format. These UML diagrams are then shared with the bigger team for an extensive design review. After getting a buy-in from the team, these diagrams are then translated into interfaces, either using the UML tool capabilities or by hand-coding them. Once all the interfaces are ready, I implement them one by one. Segregating the interfaces and the actual implementation keeps the code modular and pluggable. Testing, performance, and documentation often are add-ons. I keep them as part of my development cycle and would like everyone else to do the same as well. JSC: Can you name some things you wish you'd learned in engineering school? Gupta: In school, I didn't realize the importance of documenting. I would go through design, develop, and test cycles but would not document the design decisions or add comments in the code. This would make even my own code unreadable to me, sometimes a few weeks after I wrote it. UML designing and adding Javadocs liberally through the code has helped me write readable code. Secondly, I wish we had more participation from industry in school. It would have been good for someone currently working in the industry to talk to us about industry trends, practices, and standards. Every time I visit Delhi, I go back to my school, meet the faculty, and mingle with the students. I give a presentation on the latest industry standards in my field, discuss the importance of coding standards, and show code samples. During my last visit, I started working with some students on a new web services-related project and hope to inculcate in them the great coding practices that we follow at Sun. Java APIs for XML Web Services Addressing (JAX-WSA)
JSC: What project are you currently working on? Gupta: I am the co-spec lead for Java APIs for XML Web Services Addressing (JAX-WSA), which is JSR 261 under the Java Community Process (JCP). This project allows one to invoke web services in a transport-neutral manner. Currently, web services are mainly SOAP over HTTP. SOAP is a lightweight protocol used for exchanging structured information in a decentralized, distributed environment. XML is the most common format for defining the structure, and HTTP is the most common transport used for exchanging such distributed information. However, uniquely identifying a web service using SOAP has inherent dependencies on the HTTP transport that requires information from both SOAP (protocol) and HTTP (transport). The World Wide Web Consortium (W3C) chartered a working group (WG), WS-Addressing WG, in August of 2004 to define a transport-neutral way of addressing of web services. This JSR enables support for mechanisms defined by the WS-Addressing WG in the Java platform. Once this support is available in the Java platform, all the information currently being separated between transport and protocol is then normalized into protocol. Then it won't matter what transport is used to send the protocol message -- whether SMTP, FTP, or Telnet, the same piece of information will be sent over the wire, regardless of the transport. JSC: Where do you see web services and service-oriented architecture (SOA) going in the next few years? Gupta: We currently expose web services in a relatively controlled manner but serve them to a growing audience, as in Amazon or Google. Going forward, we want services like Amazon, which allows me to make purchases, and Google, which allows me to search, to compose with each other to form a complete system. Thus, I could search for something, buy it, and have it shipped to me simultaneously in one transaction. Today, these are three independent services. We want to make them one. SOA has existed for a long time, but only recently have service developers become more aware of its tenets and coined a term for it. Yet services are still being developed more independently -- without thinking about composability, modularity, and pluggability. For example, I'd like to pick up a search service like Google, a book catalog like Amazon, and a shipping service like FedEx and be able to compose my own web service. Currently, I must understand these various web services and create my own composability layer. I'd like to see these and similar services be composable and work together out of the box. SOA is all about an architectural style. It's not about redesigning your web service. It has its own tenets and philosophy. The basic idea is to make sure that we have clearly defined interfaces and that our services are reusable. And that we should use loose coupling so that each service can be exposed by itself. Plugging in With Microsoft
JSC: Is there any basic problem you are currently trying to solve? Gupta: Microsoft and several companies authored a slew of WS-* (pronounced WS star) web services specifications that they call WS-* specifications. For example, WS-Reliable Messaging, WS-Secure Conversation, WS-Atomic Transactions, and so on. I work in the JAX-WS (Java API for XML Web Services) engineering team and am currently working on re-architecting the JAX-WS implementation so that these various WS-* specifications can be easily plugged in. This keeps our JAX-WS implementation modular, pluggable, and extensible. Thus, if a WS-* spec is released after the implementation is released, it would be easy to incorporate support for the same in our JAX-WS implementation. I personally own the piece to implement the WS-Addressing functionality and its pluggability in JAX-WS. JSC: You recently attended a "plugfest" hosted by Microsoft in Seattle, Washington, which is part of Sun's effort to improve interoperability between Java software and Microsoft's Indigo, the web services platform. Anything to report back? Gupta: It was a great experience. I'd visited Microsoft a couple of times before, through WS-I, and I was the only Sun employee. This time, five Sun folks went together and demonstrated the interoperability of our next-generation web services stack with their Indigo stack. We talked to various program managers and engineers who are working in the Indigo team and gained a better understanding of their stack. I was glad to learn that both Sun and Microsoft have very similar concerns for our customers, and that at the engineering level, we remain focused on removing the interoperability barriers between Microsoft and Sun web services stacks. You can read more about this in my blog. Advice to Beginners
JSC: What advice do you have for developers just starting out? Gupta: As a beginner, I used a lot of vi (visual editor). But now I've been using IDEs (integrated development environments), like the NetBeans IDE, for the past couple of years, and I must say my productivity has gone up multifold. Specifically, features like boilerplate text, refactoring, and debugging are much easier to work with in IDEs than manually or using pluggable scripts in the vi environment. For instance, if I'm writing a Java bean, then I need to give the class name, field names and their types, and the rest of the boilerplate text of getters/setters is generated for me. I can set up a breakpoint when a particular exception is thrown, and the IDE will halt whenever that exception is thrown. I can change a class name or move it to a different package name, and all of its references are updated accordingly. These are simple but powerful examples. And some IDEs have very powerful features such as remote debugging. The IDEs keep me focused on the logic part of my code and take care of code logistics for me. I really recommend that new users try out different IDEs and pick one of their choice. For instance, the NetBeans IDE is available free. JSC: What has been your biggest surprise in working with the Java programming language? Gupta: I think the extent to which it has captured an audience of developers is just amazing. It was started as a research project but reached 5 million developers in a few years. This is the fastest any language has ever grown. I think it's mainly because of the speed with which the various Java libraries have evolved and the way these libraries are shared using the Javadoc format. I find it hard to imagine learning a language without its Javadocs. For instance, the latest Microsoft web services platform APIs are documented using the Javadoc format and are thus easy for me to comprehend. JSC: What Java class couldn't you live without?
Gupta: String, definitely -- JSC: What do you enjoy most about programming?
Gupta: After eight years of programming in the Java language, I still enjoy writing a simple Indian Developers in the Global Economy
JSC: You worked as a developer in India for two years and have now worked in the United States for eight. What adjustments have you had to make? Gupta: In India, I worked mostly six days a week (despite a five-day work week) mainly because of the unrealistic schedules and extreme expectations placed on a new college graduate. Having grown used to that, I tried to adopt the same culture when I came to this country. I used to set project deadlines for Saturday morning. But I soon realized that's incorrect. Other than that, I learned to push back tasks that can't be done in a timely manner. I think those are the two biggest differences coming from India to the U.S. Otherwise, there is not much difference in the working style. JSC: What has contributed to the growing number of Indian developers in Silicon Valley and around the world? Gupta: There is a lot of emphasis on mathematics and science in Indian schools, especially if computer science is your major in high school. Mastering these is essential for a good developer. Although there are bunch of native languages in India, English is the most commonly spoken language in schools, colleges, and especially at work. That helps as well. JSC: Do you have a favorite Java technology book or any book you're reading right now that you want to share? Gupta: Books by Joshua Bloch -- Effective Java is my favorite book, and I like Java Puzzlers a lot too. Also Patterns in Java, Volume 1 by Mark Grand. See Also
Arun Gupta's blog | |||||||||||||
|
| ||||||||||||
Print-friendly Version
Bio: I'm a staff engineer at Sun Microsystems in the Web Technologies and Standards team, and I have worked for more than 10 years with various distributed computing technologies, including the Java platform, C++, and web-related technologies. I am currently the co-spec lead for JSR 261, Java APIs for XML Web Services Addressing (JAX-WSA), in addition to representing Sun in the W3C WS-Addressing Working Group (WG). I have worked in web services interoperability for more than four years and participated in the SOAP Builders and the WS-I (Web Services Interoperability) Sample Applications WG.
