CIPS CONNECTIONSINTERVIEWS by STEPHEN IBARAKI, I.S.P.
Internationally Known Development Authority and Expert in Web Services, Java, J2EE, XML, BEA WebLogic
This week, Stephen Ibaraki, I.S.P., has an exclusive interview with the internationally known development authority, and noted author, Paul Perrone.
Paul J. Perrone is the founder and CTO of Assured Technologies, Inc. (www.assuredtech.com). Since 1998, Assured Technologies has been helping companies and organizations architect high-assurance software platforms and infrastructure atop of which they may deploy their applications more dependably and rapidly. Throughout his career, Paul has been instrumental in raising industry awareness of how to build high-assurance applications that are secure, reliable, scalable, available, maintainable, and extensible at various price-performance profiles leveraging use of open standard, open source, and commercial grade technologies and best practices. Paul is particularly well known for his expertise in Java, J2EE, XML, and Web Services technology. Paul has authored such top selling books as Building Java Enterprise Systems with J2EE, Java Security Handbook, and the newly released J2EE Developer’s Handbook. Due to his international reputation as a widely respected authority, Paul is also a popular speaker on software technology and has been invited to speak at venues such as COMDEX, JavaOne, Web Services Edge, and the U.S. Patent and Trademark Office. Paul has also recently founded Perrone Robotics, Inc. as a more vertically focused endeavor in developing robotics software.
His more recent book, co-authored with other experts, “BEA WebLogic Server 8.1 Unleashed,” has garnered considerable attention.
Q: Paul, with your strong and proven history in development, we are fortunate in having you do this interview. Thank you!
A: Thanks Stephen. It’s my pleasure to speak with you.
Q: Describe how you got into computing, the challenges you faced, and the important lessons learned.
A: How I got into computing goes back quite a ways. Somewhat half seriously, I first encountered a Commodore 64 in the early 1980s when I was about 13 years of age, fell in love with it, got one, and then immediately began programming and hacking around. I continued tinkering with electronics and programming until I got more serious with some projects during my undergraduate and then graduate collegiate years. That is when I began to really understand what is involved with creating commercial-grade applications and ones that affect mission-critical systems in particular. I was funded during graduate school to develop a high-assurance hardware and software co-design for detecting safety-critical errors in railway applications. We had to invent new approaches to detecting software and hardware errors throughout massively distributed railway systems such that the trains, switches, and signals could fail-safe. I basically learned that while it was impossible to quantify things like safety, reliability, security, and other assurance aspects when software is involved, you can at least employ artifacts from a “bags of tricks” to enhance the assurance at a qualitative level but with a rigor that most in the software community don’t employ.
Q: How about two stories—any with a humorous slant?
A: I have plenty of stories. A more serious one involved an E-commerce site for which me and other folks at Assured Technologies were involved with creating the software. We helped architect a very solid system that was running well and as usual increased availability and enhanced their performance beyond their expectations. One day, however, the servers were just dying and no one knew why. Nothing new had been added and we were completely puzzled. We weren’t sure if it was a denial-of-service security attack or what. After some very targeted and surgical analysis deep inside the bowels of the underlying application server products that we were using, we discovered that when a certain number of server objects were pooled, that instead of caching state to disk, the server just died. This was not documented or expected behavior. I like the story because it illustrates the fact that problems occur in enterprise environments whereby you have multiple versions of many different software pieces and problems can lurk in the darkest corners. The humorous back-story to this was that a co-worker and I were at completely different locations across the country when our pagers went off and began to address the problem. It was also the night of Saint Patrick’s Day and we were both out celebrating with friends. Those are not ideal problem solving conditions but the problem was solved despite the fact. It helps to eat, sleep, and drink your work.
Q: Describe your current role and projects?
A: I’m the CTO at Assured Technologies. We’ve been around since 1998 helping companies architect and build high-assurance software platforms and infrastructure atop of which they can more rapidly and dependably deploy applications. I try to play a part in many of our various projects to help set the stage on how to solve the problems our customers are having. I am involved with some projects more than others depending on the needs. We have a variety of on going projects and all involve leveraging our expertise in Java, J2EE, XML, and Web Services technology coupled with our ability to help develop high-assurance infrastructure. I bring to the table a focus on how to architect the systems for reliability, scalability, availability, security, maintainability, strategic evolution ability, and other facets of design. I’m also involved with a robotics start-up applying some of my infrastructure knowledge to the more vertical applications space of robotics software infrastructure. I also do a lot of book and article writing as well as talks.
Q: Where do you see yourself and your company in five years?
A: Assured Technologies was doing some product development work a while back, but we’ve shifted our business model to focus on our core competency of consulting and being world class architects while maintaining our detailed knowledge of development concerns. We also focus on those technologies that are open standard, open source, and commercial best of breed. With a solid focus now on architecture and consulting, we’re going to target specific project types and grow our company to retain the best and brightest in industry for architecting high-assurance platforms, infrastructure, and systems. We have no desire to be a body shop of haphazard code slingers. Rather, we want to be the firm that the big companies and organizations think of when they need an enterprise-class software architecture group and prime contractor for their projects. We would also like to continue lowering the overall cost of development so that we can do more with less and see more interesting applications out there and ones that work. I see myself helping the company get to this point of being industry’s most reputable software architecture firm concurrent with the time I’m spending spinning up Perrone Robotics, Inc.
Q: Detail Perrone Robotics Inc.
A: I am excited about this. I started out developing software for some mobile autonomous robotics R&D work I was doing. I then took some time out to create a business plan around this idea for developing some software infrastructure for robotics applications. We are all about software for robotics and make it cost effective to deploy more rapidly mobile autonomous robotics applications into the broad consumer and professional business space. There are also some good applications in the defense arena and we’ve been working on some proposals to DoD agencies for applying some of our work inside of future combat systems. Our work leverages use of some very low cost and open source products to make it ridiculously cheap to do some very interesting and sophisticated robotics work. I’m talking at about one thousandth the cost of what competing companies and academic groups are doing.
Q: What are your thoughts on the Open Source movement?
A: I think there have been some excellent gems that have emerged from the Open Source effort. There is also a lot of garbage that has emerged. However, the gems that have emerged are great for speeding up the deployment of solutions at lower cost of development so it has been worthwhile for us to leverage use of such gems on projects for our customers when appropriate. There are also times and applications where certain products are not scalable enough and we leverage other commercial best of breed products. I think we will continue to see some Open Source gems evolve and emerge, but I am also concerned that certain legal proceedings could affect their proliferation. There really isn’t any case law and there are no “open source lawyers” that I know of to defend these projects for free in the event of aggressive litigation. So there are some risks, but I think that will be self-correcting and we will continue to see other gems emerge and evolve.
Q: Describe the future development of XML.
A: XML will be the lingua franca for representing data and information inside and across enterprises. Every new software project or product built is or should be leveraging XML as the way to represent data. Be that data that represents information in a communications packet ala Web Services, data in a configuration file, data in a database, or what have you, I see XML as the data representation standard moving forward.
Q: Describe the future development of Java and J2EE.
A: Much like for civilizations to evolve, we first had to have human languages, rules, laws, and other human services standardize and stabilize, so too is the case for enterprise application civilizations to evolve. That is, we need to have a stable and widely adopted language like Java and a stable and widely adopted set of standard services and interfaces atop of which we can develop our applications. As a language and platform, Java and J2EE have really taken hold and are very widely adopted. What’s great about them is that they are also very well engineered platforms from a technical perspective. I think they are here to stay and will evolve to enable us to develop cooler and more sophisticated applications with components that will be reusable for a long time to come. I don’t think we’ve seen anything else like this in our industry’s history so it’s hard to imagine the fact that the language and platform will be around for a long time, but I think they will and we’ll all benefit from that.
Q: Detail the evolution of Web services, past, present, and future.
A: Web services had an interesting beginning with Microsoft initially being a prominent player in helping define this XML-based remote procedure call standard. I was glad to see the Java community fully adopt and incorporate XML-based standards into Java and the J2EE since it gave the standards further legitimacy and usefulness in actual enterprise environments. We are at a stage now where people are realizing that the standards need to be resolute in their approach to inter-operable security and transactions. The nice thing about J2EE is that you can rapidly and easily expose your components as Web services and leverage some of the security and transactional features that have been built into J2EE from the start. However, across the Internet, inter-operability will still lag until the security and transactions from the Web services standards folks stabilize. I would also like to see stateful Web services standards evolve to make it more practical to deploy service-oriented architectures within an enterprise. The fate of Web services is in the hands of the vendors implementing the solutions to determine whether we will have global scale, islands, or ivory towers of inter-operability.
Q: Provide important tips on Java security.
A: There is a tremendous amount of stuff built into Java to enable one to build secure applications. My primary tip is to take it upon oneself to understand the various things available in Java security to understand what exists, when you might use it, and when to use one technology over another. Know that you have standard interfaces for authentication, authorization, encryption, integrity, and SSL available to you within the core Java platform. Also, know that when you are building J2EE-based applications that you can shield the developer from having to know many of these interfaces by virtue of J2EE container-managed security features. Once you know what you have available to you, then you can again know your “bag of tricks” for application in practical situations.
Q: Can you provide business models for the use of SOA and Web services?
A: Sure. As I described earlier, the standards somewhat lack right now in providing a definitive model for Web services security and transaction inter-operability. Hence, many businesses are either building Web services on the Internet that don’t require secure interfaces (e.g. content search services), that do have security-critical needs but operate behind a secured firewall, or simply employ a non-interoperable security solution. Those are the business models now. That’s the practical fact of life right now about Web services and hence why they haven’t been as widely adopted as the hype may have alluded. Strategically, we also work with companies to ready them for the holy grail model whereby security will be standardized and accepted by the community, and subsequently enable one to build Web services for more sophisticated business-to-business collaboration as originally promised by the early Web service evangelists.
Q: Share your insights from your speaking engagements such as at Comdex and JavaOne.
A: COMDEX and JavaOne are completely different audiences. When speaking at JavaOne, I am speaking with developers, architects, and technical managers in mind. The discussion and questions I get there are at a level whereby the folks want to know how to solve particular problems without glossing over the details. I enjoy those sessions a lot. At venues like COMDEX, the audience is more diverse. The discussion and questions are focused on what one can do with a particular technology, its features, its issues, and more business-related aspects. I enjoy those sessions too as I try to speak at various levels of abstraction.
Q: If you could only go to one conference, which one would it be and why?
A: That’s a tough one. Well, I love Las Vegas and the craps tables, and COMDEX and CES have a broad interest base and are in Vegas. However, JavaOne is critical from a Java technology point of view, knowing what others are doing with the technology, how they’re doing it, and what is coming up in the next year. I also enjoy speaking at the No Fluff Just Stuff symposium series, which are smaller venues across the county but are very developer oriented conferences. Because I’d like to continue to be invited to all of those conferences I’ll give you the political answer that I love them all equally. I would like to see more conferences in places like Las Vegas and Hawaii though.
Q: Describe the BEA WebLogic platform.
A: It’s a great platform. I have a lot of respect for the engineering effort that has gone into BEA WebLogic. They built a very solid platform that usually implements the J2EE standards strictly and well. I’ve always liked their clustering features too for building highly scalable applications. WebLogic can be costly though, so it isn’t the platform to use for all scenarios. But BEA has also defined different profiles to enable more flexible selection of the platform to get you the price-performance profile that is acceptable for you.
Q: What about the future evolution of WebLogic?
A: As a user of the platform, I can only say what I hope to see. I hope to see them religiously adopt the J2EE standards early and fully. Granted that pure J2EE implementation can commoditize a product and hence lower the revenue BEA will get from the J2EE-based part of their platform. However, they also have and I suspect will continue to add other features to their platform and atop of the platform to make the J2EE server itself a viable platform to offer. Might be interesting if they Open Source their J2EE platform itself sometime. Might really drive customers to their other products.
Q: How do you differentiate your WebLogic book from others in the market? Why should our audience read this book?
A: It is very timely for one. It covers the latest and greatest in WebLogic 8.1 technology and its interfaces for developers. It is also very comprehensive. I was amazed to see the end result with well-organized coverage of all the key topics that a developer working with WebLogic 8.1 will need to know. I think people are also learning that Sams Publishing has really been pouring a lot of effort into getting practitioners to write books based on first hand experience with the technology. As a result, this book is a very hands-on how-to that speaks directly to the type of questions on developer’s minds versus just a regurgitation of specifications or academic postulations.
Q: Give us some insights into configuring hardware and software for a successful WebLogic installation.
A: Well, for one, you need to have a rough estimate for the number of transactions per unit time you will be dealing with for your particular application and how that will scale with time. Armed with that knowledge, you can take a first shot at the computing hardware that you will need and how to distribute WebLogic processes across those machines. Sizing will dictate things like number of processes per machine, processes per cluster, number of clusters, collocation or disparate Web and application server processes, collocation or disparate proxy servers, and network load balancing architecture. After you’ve sized you application, the process architecture, and the hardware architecture, you then have to consider what application level design features you need to employ to facilitate clustering, load balancing, process start-up, process shut-down, new code deployments, and other operational features. Obviously, there are a lot of details behind how to do this but that is the general approach I take to start thinking about the problem.
Q: Talk about leveraging J2EE APIs for handling transactions, messaging, databases, and mail services.
A: We have made significant use of specifying transaction boundaries that the J2EE container manages using the declarative XML-based deployment files associated with J2EE components. It definitely is a lot easier to define transaction boundaries declaratively in configuration files versus baking transaction management logic inside code. However, I must admit that the model is somewhat limited in that only flat transactions are supported and I would like to see support for nested transactions and transactions with Web services. J2EE for messaging and database access are very popular in the real world. It has been an easy task to hook into various types of messaging services using the J2EE JMS API and message-driven EJBs and we have applied it to all sorts of enterprise application integration problems. Database access via JDBC and EJB is also always a factor and consideration when building enterprise applications and we have been able to build many reusable components that are able to work with a variety of databases by leveraging the APIs. We have used J2EE’s JavaMail primarily to send out email from within the server after certain events take place such as for sending customer order notices, security alerts, and other system event alerts. JavaMail also supports the ability to retrieve email but very few applications we have built have had that need.
Q: What are the best practices and design strategies for Enterprise JavaBeans?
A: The first key to using EJBs is to know when they are appropriate to consider for usage. We use EJB when building applications that must scale, be secure, have transactional properties, and have other high assurance requirements. Many organizations, including my own, leverage use of stateless session EJBs for encapsulating high assurance business logic and message-driven EJBs for providing an asynchronous front-end to high-assurance business logic. Some folks have expressed dislike for stateful session and entity EJBs because they are conceivably too complicated to use. That is a fair argument but I think a little time invested in learning how to use them properly can go a long way and save you headaches and time in the long run when you want to more rapidly and dependably build total enterprise applications. One key for making their use easier may be to look into development tools or perhaps build your own frameworks that make it easier to generate some of the infrastructure (such as interfaces, stubs, skeletons, and deployment descriptors) required when deploying EJBs. We have built our own tools and have used various tools that ease EJB development enabling us to utilize the full range of EJB types resulting in a greater ability to build higher-assurance applications. EJBs as well as Java Servlets have also more recently been imbued with the ability to be deployed as Web services, which is an exciting new development that we’re putting into practice.
Q: What additional tips can you share from your book?
A: The J2EE Developer’s Handbook is a 1500 pager and it is heavily loaded with tips and frank discussions on workarounds. Therefore, I will try to extract a general tip. A general tip is to know what features the various J2EE technologies provide for you and at a level that enables you to understand what the APIs offer and how you might go about applying them for the types of problems they aim to solve. Such a technological “bag of tricks” will help you better select the right standard J2EE technology for the right situation while also knowing what limitations exist with J2EE such that you can plan to build or buy components that fill those existing gaps.
Q: Provide your predictions about the evolution of hardware and software. Are there any areas we should be watching?
A: Naturally, I think hardware will get more powerful and smaller. That is good news for Java technology branching outside of enterprise applications. We are already seeing more and more well performing and feature rich desktop applications and entire desktop environments such as the Java Desktop System (JDS) as a result. We are also seeing an abundance of embedded Java and J2ME applications proliferating cell phones, PDAs, and other constrained environments. I would definitely be keeping an eye on this trend that is in motion because we’re going to see extremely sophisticated end-to-end applications out there whereby J2EE servers are hooked up with Java desktop applications and embedded Java applications. The mobility of Java code across such environments is really exciting, not only in terms of how code updates can be transparently disseminated across distributed applications, but also in terms of how mobile business logic and agents can run in a massively distributed fashion across a network. I see this feature mainly being leveraged inside a particular enterprise environment but also see opportunities to leverage these capabilities within end user consumer-oriented products.
I see Web services becoming popular too albeit more slowly than originally hyped by the vendors. Web services will somewhat prohibit the ability to send mobile Java code across applications, but will make it easier for islands of enterprise systems to inter-operate when those islands have been created by different organizations.
Q: Share your top ten study tips for learning about WebLogic Server 8.1.
A: 1) Take some time out to understand the constituent J2EE APIs and features.
2) Download or procure a copy of WebLogic 8.1 and step through the installation.
3) Start out by doing something imminently useful, yet simple, like creating an example JMS producer and client talking to the WebLogic JMS server.
4) Then create a J2EE component by creating a simple JSP and deploying it inside WebLogic.
5) Install and configure a sample database and configure some WebLogic JDBC connections for that database.
6) Engineer your JSP to talk with the database using those JDBC connections.
7) Move your JDBC code inside of a bean-managed persistent entity bean and deploy it with the JSP talking directly to the entity bean.
8) Create a stateless session bean that talks with the entity bean and have the JSP talk with your session bean.
9) Code that entity bean as a container-managed persistent entity bean and engineer your session bean to talk with it instead.
10) Engineer your JMS consumer code to be implemented as a proxy to the session bean.
By going through those steps in roughly that sequence, you will have tapped many of the main features involved with architecting an enterprise application using WebLogic by example.
Q: What are the ten most compelling issues facing technology professionals today and in the future? How can they be resolved?
A: 1) Offshore outsourcing is an issue for many IT folks in the U.S. There never is any replacement, however, for being a good communicator close to the business folks and demonstrating your ability to more rapidly and completely digest their needs and translating that into code that not only works as intended but is of high quality.
2) Open source is both a blessing and an issue for many. It is hard to compete in a product space whereby someone is offering something for free. You can either adopt their free product and augment it yourself or you can export that competing portion of your product for free and add value with auxiliary product features and services.
3) Obtaining correct, complete, logically structured, easy to comprehend, and easy to test requirements is a historic yet a current problem today. IT professionals can accelerate the process of extracting requirements by working closely with the business folks and end users, and attempting to transform their goals and needs into a format both understandable by them and by engineers. Use cases and scenario diagrams work well in this regard. Another way to solve the problem when having incomplete and changing requirements is to architect your system such that it is generic and flexible enough to be more easily and rapidly changed as requirements are discovered and change.
4) Reasonable project time management is again another historic yet current problem. If you have a project manager that understands engineering and how to make reasonable time estimates, they are worth their weight in gold. When in a situation whereby time is simply at a premium and the schedule is shortened beyond reason, you have to set expectations early about what will be produced and provide a well-defined description of the deliverables to expect given the time frame involved. You also need to be able to communicate in an objective and non-whining fashion about the issues involved with the time frame.
5) Keeping abreast of the rapidly changing and expanding technology space is difficult. Make it a point to always reflect on the type of technical problems you are encountering or expect to encounter when working and then try to target specific technologies that seem to address those problems. Target those technologies by learning what they are and test them out if you can.
6) Finding work can be an issue. Networking with people is difficult for many engineers but it is an essential task that needs to be employed. Target the right people and venues for networking professionally and keep in touch with colleagues past and present.
7) As technology standards evolve, the underlying layers of the application stack commoditize. A skill learned and mastered yesterday may be commoditized tomorrow. Hence, always climb the value chain and learn higher-level application development skills.
8) Product version madness can be a problem. A feature that you relied on yesterday in a vendor’s product may not be available in their next version or may not operate with another product integrated into your overall solution. Keep track of what versions of software, both custom and third party that you used in development when building a solution. Then make sure those same exact versions make it into QA and production via a version description document.
9) Resolve hype versus reality early. Many new standards and technologies are hyped by marketers to generate industry momentum and traction. Ninety-nine times out of one hundred, some key implementation ingredient that makes use of such technology viable in your particular situation will not have been communicated along with the hype. Discovering this late in the process of using the technology can be bad, so before investing too much time in leveraging a new standard or technology, make sure you investigate it early.
10) Make time for socializing with family, friends, and colleagues despite all of the work things to worry about and spend time on. “Extremist engineers” have a difficult time presenting a human face at work that affects their ability to network, communicate with management, and communicate with peers.
Q: List the 10 best resources for technology and business professionals.
A: 1) The Wall Street Journal is my favorite resource for general business information.
Q: You pick the topics: now provide us with those valuable rare “gems” that only you know.
A: I spent an enormous amount of quality time in graduate school trying to create accurate yet manageable models for how computing systems behave. While this was done in the course of trying to understand how to model the failure modes of hardware and software, it yielded a very deep model for how systems at any level of complexity behave. I’ve refined that model a bit over time as I put it to practice in industry, but I’m amazed at how robust much of it has been. The model has evolved and it has been sort of a guiding light for me in how to more rapidly architect a system and imbue such a system with high-assurance properties such as reliability, availability, scalability, security, maintainability, strategic evolution, and performance. Over time, I’ve also evolved the model to know how to structure a system architecture for optimum modularity. Bits and pieces of the model have been communicated in various works that I’ve written but I’d like to one day sit down and capture the model for others to digest and evolve.
Q: What future books can we expect from you?
A: My work in the robotics space is likely to yield some publications including work on rule engines, discovery and lookup protocols, and agents. I’m also interested in publishing that manifesto on system architecture and modeling that I alluded to in the previous question.
Q: What do you consider to be the most important trends to watch, and please provide some recommendations?
A: Sure. I’ll give it a go. I’ll categorize the trends into those that are occurring now, those that are occurring now but will take off big time soon, and those that are a bit down the road.
1) High-speed Internet everywhere (soon).
Q: What kind of computer setup do you have?
A: I have numerous platforms in the home and office. I run Linux on the server side mainly and currently have a lot of Windows client machines. I’m considering a move to Apple very soon on the client side. I’m also going to start looking at the Java Desktop System very soon.
Q: If you had to do it all over again?
A: I would have bought a ton of crazy Internet stocks in 1999 and dumped them all in 2001 before the bubble burst. I’m hearing people saying officially that 2004 will be a good year. Unofficially many are saying that it is going to be an amazing year for our economy and technology. We’ll see. But this time I want to invest early and wisely and monitor the companies closely.
Q: What drives you to do what you do?
A: I simply love technology, what computing platforms can do, and what I hope to help make them do in the future. At the micro-economic and shorter-term level, creating something and having it affect some desired result and function inside of a business or application is very rewarding. At the macro-economic and longer-term level, seeing computing benefit humanity and doing things for us that enable us to literally evolve our lifestyle and world is pretty wonderful. I find it all very exciting and would like to do bigger and better things with technology and watch it benefit and be used by people and organizations along the way.
Q: How do you keep up with all the changes?
A: I think communication with other people at conferences, symposiums, networking events, and in the workplace is the best way to keep abreast of what is going on in the real world. For a broader view, reading magazine articles, surfing Web-based resources, and reading books is of course a must. Finally, when I sit back and start writing a book or article, it often forces me to ask even deeper questions about a particular topic as I write about it and that spawns an iterative information gathering and vetting process that I find rewarding.
Q: Paul, thank you again for your time, and consideration in doing this interview.
A: No problem Stephen. It was my pleasure to reflect. Great questions and a fun time.