|
|
|
|
CIPS Connections
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. 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.
|
|
News Contact Sitemap HOME |
Copyright © 2000 - 2004 Canadian Information Processing Society All rights reserved. Terms of Use Privacy Statement |