NobleNet Inc. - Two Customer Profiles
As part of a public relations project, GEIBEL Marketing & Public Relations prepared several customer profiles for NobleNet Inc. These profiles were then used for the NobleNet public relations program that we conducted for them. NobleNet was a vendor of remote procedure call (RPC) messaging topology that is used in N-tier client-server systems designs and also for Internet-based systems. The SABRE profile resulted in a product review in Data Management Review, and in a feature article that was scheduled for publication in Windows NT magazine. In early 1999, NobleNet was acquired by Rogue Wave Software, and ceased to exist as a corporate entity.
NobleNet's RPC 3.O Helps SABRE Build Business Travel Solutions
NobleNet's RPC 3.0 is a key element of SABRE's new corporate travel booking
and management product, called Business Travel Solutions (BTS). Based on
a three-tier client/server architecture, the BTS design utilizes RFC 3.0
for communications between the clients and application servers, load balancing
on the application servers, and multi-threaded parallel processing. The BTS
system is an integration of best-of-breed products for large-scale, real-time
client access to many data sources, including relational databases and
computerized reservations systems (CRSs).
BTS was designed and developed by a unit of The SABRE Group, Inc., called
SABRE Decision Technologies (SDT). SDT is a business solutions company providing
decision support systems, software applications, systems development, and
consulting services to over 250 clients in more than 50 countries worldwide.
It is a $350 million company with 3,300 employees that focuses on providing
leading-edge technology, on a global basis. BTS is offered by SHARE Travel
Information Networks (STIN, which is another unit of The SABRE Group. The
SABRE Group's parent company, SABRE Group Holdings, Inc., recently issued
an IPO. Previously, The SABRE Group had been a division AMR Corporation,
perhaps best known as the parent corporation of American Airlines. Since
1988, SDT has been providing technical solutions both to business units of
AMR as well as outside companies.
One of SDT's responsibilities has been to support the users of the SABRE
CRS. This system, widely used by travel agents and corporations, consists
of data on thousands of airline flights, hotel properties, car rental agencies,
and other travel-related data. With the BTS system, STIN's and SDT's objective
is to allow corporate traveler access to SABRE travel information, with the
ability to check availability and book trips directly while following corporate
and departmental policies.
BTS is based on a three-tier client/server architecture. Richard Pendergast,
Senior Programmer-Consultant, describes the goals of the BTS project: "We
are giving corporations the opportunity to do their own legwork for travel
planning. The travel agent will still issue tickets, answer questions, book
the more complex trips, and provide corporate reporting that the travel agency
is normally responsible for. BTS will make the travel agent more efficient
by allowing the customer to book their own trips in most cases. What we have
built (with BTS) is middleware that incorporates business logic, and the
architecture is independent of that business logic. Our system allows lightweight
clients to communicate with our middleware that in turn communicates with
data sources, such as relational databases and the SABLE CRS. The architecture
has many other applications, due to the fact that it can change out clients
and business logic rather easily. This flexibility comes in part from the
capability of the application servers to talk to each other using the RPC
3.0 system. This way, we can distribute the workload using server-to-server
communications-one server being a client of another. This distributed processing
is a form of parallel processing. RPC 3.0 is also used for load balancing,
which is the ability for the end-user client to ask for the most available
(server) system. The system will then transparently redistribute the work,
utilizing RPC 3.0 to accomplish that. Also, if a particular problem is too
big for one server, the architecture can distribute it among several servers.
For customers who have a desire and need to secure data, our architecture
can secure that data on another, separate network. This "secure network"
is then attached only to the application server. We use the server to
authenticate every user, which is better than firewall technology. Conventional
firewall technology normally isolates communications at the network level.
We want to isolate the client application from having direct access to the
data sources," adds Pendergast.
Mark Wedge, one of the principal programmers on the BTS project, comments:
"The BTS project is a three-tiered client/server system. In the middle is
the BTS application server (Intel or Digital Alpha servers running Windows
NT). The back end is the relational database that holds policy and trip data,
and the SABRE host system. The front end is a BTS client, which is a standard
Windows-based application. The business logic is held in the application
server, which sits in between the front and back ends. RPC 3.0 is used for
all communications between the clients and the application server. The clients
are the travel planner client and the policy management client."
During the architecture development period, when laying out the platforms
and communications protocols that had to be supported, Wedge suggested RPC
3.0, due to his prior experience with the product. He set up a quick prototype
using RPC 3.0, and also evaluated the effort for writing a "home-grown" system
by hand, which would have involved developing the communications layers,
writing to TCP/IP sockets, and developing for several platforms. He estimated
the coding effort for the "home-grown" system on one platform to be about
six months. Using RPC 3.0, he completed the client/server communications
effort in about two weeks. "With RPC 3.0 it is real easy to include security
and load balancing on the servers. We have five servers that are talking
to each other-they know each of their client loads and can transfer requests
to other servers when necessary. RPC 3.0 can also handle complex data structures.
Our architecture has many functions plugged into the back end, that is, pluggable
modules in back. So we architected a generic type function call, a big binary
block of data which we encode into the data stream. The NobleNet RPC then
allows the various functions to pick off the data they need, unlike most
RPC programs that want to know the arguments passed for each function."
Pendergast expands on the RPC 3.0 applications throughout the BTS system:
"We use the object model for clarity and all the benefits of object orientation.
Where performance is paramount we balance the desire to be object-oriented
with the desire to be very fast, since constructors and destructors involve
some overhead which can cause performance problems. Where there is a conflict,
we choose the route of fast performance. What we have developed is a layered
architecture with an AFI that is well defined at each layer, and a common
method to get information from one layer to another. RFC 3.0 supports both
methodologies."
Scalability and flexibility are key components of large systems architecture.
Pendergast discusses the role RPC 3.0 played in providing those capabilities:
"Another differentiating issue is scalability. That is, the ability to take
the system and just multiply the servers. The BTS system is both infinitely
and naturally scalable. With the load balancing module it is very easy to
increase system capacity. There can be any number of data sources on the
back end-it can be l, 10, or 100. The system can also talk to web servers.
If the customer wants Internet or intranet access, they can just use a web
server, and simply snap in the technology to connect the web server with
an application server. So the web-based clients use the exact same business
logic modules as the Windows-based clients. The beauty of the system design
is that you don't need to know what kind of client is involved, since they
all communicate with the application server via RFC 3.0. It is a cross-platform
tool which helps support both scalability and expandability."
The underlying architecture of the BTS system has potential uses far beyond
the immediate needs of the BTS project. Richard Pendergast outlines the vision,
and the role RPC 3.0 has played in that vision: "SDT is a consulting company
that is definitely interested in exploiting the advantages we have. We have
a lot of experience in building large systems for large volumes of users-we
understand that business. Our solutions are highly networked, involving large
projects and large solutions. We are looking for the best tools to bring
that about. We are very happy with NobleNet. We have had quite a few vendors'
products in here. NobleNet has been wonderful in solving issues, and it'
s not easy to find companies with that kind of approach.
NobleNet has never been a problem in getting to a solution - they have always
jumped on the issue. In my opinion, they always deliver their best possible
effort."
NobleNet's RPC 3.0™ Helps Blueridge Technologies
Get More Done With Less
Blueridge Technologies is the vendor of OPTIX™, the only industrial-strength document management system that is optimized for Macintosh™, Windows™, and the Internet. An OPTIX system can include Workflow, Document Imaging, Text Retrieval, Document Management and Control, Optical Storage, Optical Character Recognition (OCR), and Computer-Output-To-Laser Disk (COLD). OPTIX is based on industry standards such as SQL databases, UNIX and NT servers, and TCP/IP. Blueridge Technologies was founded in 1988 by Dr. John Jamieson and Craig Landrum, pioneers in the development of some of the largest document management systems ever designed-including the Automated Patent System in use at the United States Patent and Trademark Office. Blueridge's customers include Apple Computer, Federal Express, Genentech, Motorola, the US Army, New Haven (California) Unified School District, and Howard University. OPTIX systems can range from five-seat versions costing $40-$50,000 up to systems with hundreds of concurrent users costing $1 million or more.
Blueridge faced some significant challenges when it began development work on Version 5 of its software. Version 5 was a very ambitious development project. The software needed a complete rewrite to take advantage of object technology both for the purposes of maintainability and getting software upgrades and enhancements to the market faster. Jim Small, Director of Server Development at Blueridge, describes the challenge: "Up until then, we were doing our own protocols over sockets. This resulted in very fast execution of code, but it was very laborious to code up and to debug. Getting things into a data stream and out of a data stream is both tedious and drudge work. Our programmers hated it. Although we had the Version 5 rewrite on the books for over a year, we hadn't made headway until about January of 1995 when we started dealing with NobleNet."
To fully understand the enormity of the challenge of rewriting the OPTIX applications software, it is perhaps useful to understand the components of an industrial-strength electronic document management system. Any document management system needs three aspects to be a total system: an archive repository file, which makes the data accessible; a full text search index and query engine with an OCR engine that takes files and filters them and also extracts text; and a work flow component which takes the files and defines a process for the files to go through - this flows the documents from inception to the end point in the process. OPTIX has all three of these components and is one of the few vendors (out of about 200) that supports cross-platform systems (both Macintosh and Windows.)
Blueridge's proprietary protocols, although optimized for transaction speed, carried with them some liabilities. Jim Small explains: "The old API protocols were so laborious for the programmers to modify, that it resulted in a reluctance to change any features. There was significant resistance to adding functionality that would require a change in the data transactions, and hence recoding the protocols." Briefly stated, Intel and DEC machines use different byte-ordering and data alignment rules than do SUN and Macintosh machines. Since OPTIX is an open architecture, cross-platform product, these differences spelled massive coding headaches for Blueridge's programmers. NobleNet's RPC 3.0 handles those differences seamlessly. "Going to RPC3.0, from my perspective, was the best thing for the product," adds Jim Small.
Small expands on the benefits of NobleNet RPC 3.0: "If someone has an idea or innovation, with RPC 3.0, you can bring the functionality to market quicker, (on average 20 to 30% quicker) and also eliminate significant programmer resistance to adding functionality. With our OPTIX workflow rewrite, RPC 3.0 will cut development time in half. Coding for an imaging or archive server involves writing interfaces which in effect breaks down as: one-third network protocol, one-third database, and one-third server logic. RPC 3.0 effectively eliminates the need to write the network protocol. With RPC 3.0, once you know the data structure - you tell RPC 3.0 what the data structure is and it writes the code to transfer that information across the network."
Small first became aware of RPC 3.0 when he had seen an announcement of the NobleNet RPC 3.0 for the Macintosh. He obtained an evaluation copy and found it very easy both to code and debug. He found additional benefits: "It also provided an ability to do APIs (application program interfaces) that we could offer with the Version 5 product - so others could develop applications to use with our system. We actually bought into NobleNet around March of 1995 and by May had developed a prototype." Blueridge signed a contract with NobleNet in June of 1995 and between June and September rewrote the imaging piece of their applications software (which is both the client piece and the server piece) based around RPC 3.0 technology. What Jim Small and his programmers found was that all the drudge work went away. NobleNet RPC 3.0 allowed them to focus on functionality rather than the coding minutia. Craig Landrum, Blueridge's Chief Technical Officer, asked Jim Small what he thought of NobleNet. Small told him that at least one-third of his expected development effort was eliminated, due to NobleNet RPC 3.0. "It was like hiring additional programmers. Since September, we have developed the text search piece using the Excalibur Technologies engine, and rewriting the workflow part using RPC 3.0. Having a tool that reduced the amount of development time like that is like having extra people. Previous to RPC 3.0, I can't imagine signing a contract in June and delivering so much code in September. We simply couldn't have done it without NobleNet." Jim Small concludes: "RPC 3.0 is one of the few middleware tools that I would actually recommend - it significantly decreases development time, improved the quality of our product due to reliability, and if you are interested in supporting different platforms it makes that very easy because it runs on almost any platform."
CEO Dr. John Jamison adds his views on NobleNet RPC 3.0: "Time to market was the biggest factor in the decision to use NobleNet. Another useful thing is having an API that is more generally used than one of our own which is more proprietary - if you are not in the RPC business you want to learn to write RPC code. RPC 3.0 decreased our risk. By doing your own APIs you run risk that you will take time to learn things that NobleNet has already learned. Indirectly, it freed up Jim and his group to do things he would not have been able to do, to respond to customer requests in a way that he would not have been able to do before, and simply stated, NobleNet RPC 3.0 let us do the things we know how to do best. If I were speaking to one of my peers on this issue (RPCs), I would tell them RPC 3.0 does what we needed it to do, it does what NobleNet says it will do, and we implemented it with a minimum amount of struggling with issues that we would have otherwise struggled with - it's been a good investment for us."
RPC 3.0, and NobleNet are trademarks of NobleNet, Inc.
OPTIX, OPTIXWEB, OPTIXCOLD, OPTIX WORKFLOW, OPTIX NLS and FILTERTEXT are trademarks of Blueridge Technologies.
Copyright 1999 Jeffrey P. Geibel, All Rights Reserved Return to Index Page
Related articles:
Articles Master Index Page for One Stop Browsing Think Twice About that Press Release - You May Have Entered The Google Zone Broadcast PR: Working with Community Access Television Are You Sure You are "On-message"? (Sales Messaging) Can Your PR Program Crossover to the Mainstream Business Media? Developing a Thematic ReleaseSM
Program for Channel Marketing How to Build a Sales Public Relations Program Marketing ROI Part I: Estimating Your ‘Reachable' Market Potential Losing the Battle for Mindshare: A Guide to Ineffective PR Internet Damage Control: How to Prevent and Defend Against a Web Mugging What Your Web Site Says About Your PR
Savvy Using Public Relations to Leverage the
Hidden Code in Your Successful Sales
How Digital Tools and Audiences are Changing
Public Relations for Technology Businesses
The 5W's for Direct-to-Web Public
Relations
Looking for Mr. GoodInk - How to find the
PR Advisor that is Right for Your Company
Complex Technology Requires an Intelligent,
Sales-Based Public Relations Program
Caveat Expectation: Public Relations Strategies
for Emerging Growth Companies
How to Bridge the Chasm, Not Just Cross
It
Marketing Architecture for Business Sales
Kennedy Crash Shows Public Relations Lessons
Learned from TWA Flight 800