Careers: Interviews
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.
Discussion:
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.
2) Web search engines and
Google’s news groups can yield just about any information you need
in a pinch.
3) Well engineered how-to
books on a particular technology subject can be invaluable for
launching you down the path of understanding a technology and as a
reference. Of course, I include those books written by me via Sams
Publishing in that category. While I like reading books from other
publishers as well, I think Sams has the “nuts and bolts”, “to the
point”, and “how-to” approach that developers really appreciate.
4) The Web site
java.sun.com is of course key for Java developers looking for
specific versions of specifications, downloads, and API references.
5) Hot links to
documentation for whatever J2EE server you are using are also of
course key.
6) I think the Java
Developer’s Journal is an excellent journal for also keeping up on
Java technology.
7) Conference wise, I
like JavaOne and the No Fluff Just Stuff symposium series for
meeting others in the Java community and keeping abreast of what is
going on.
8) General technology
wise, I read magazines from the ACM and IEEE as well to know what is
coming down the pike.
9) I also like to read up
on laws revolving around my business and technology (believe it or
not). That includes patent, copyright, contract, and other relevant
law categories.
10) I like reading the
BBC online to know what is going on in the world at large.
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.
|