Corporate Website

The following is part of the outline and some of the copy I wrote for a web site redesign I managed for a SaaS business customer, New site graphics were created by local designer I contracted.

Redesigned Website

Redesigned Website

null line

RPM Architecture

RPM, the RevX Process Management system, is peer-to-peer software technology that creates, through existing security firewalls, a virtual entity for group effort and process management. Collaboration systems generated with RPM let organizations collaborate efficiently, securely, and automatically with their external as well as their internal suppliers and process partners.

Browser-based, RPM processes are instantly deployable at your site or through ASP hosting. RPM allows direct communication between business partners — without compromising internal security. RevX’s powerful process authoring tool allows customers to quickly define their processes in XML. Moreover, RPM’s robust integration capability preserves your investments in legacy data and your current manufacturing systems.

The RevX technology platform is designed for complex processes involving coordination of thousands of suppliers and other business partners located anywhere in the world. Features include:

  • Integrated community
  • Flexible display options
  • Support for Oracle, Sun, and Microsoft hosts
  • XML-based
  • Modular & extensible services
  • Node-to-node communication
  • Back-end integration for interoperability with legacy systems.


How does RevX let your external suppliers, contractors, and partners join your RevX notification and escalation process fully and securely? Without you setting them up as a user inside your firewall? And without drilling a hole in your firewall?

Answer: by making the partner a user on the RevX portal node. The beauty and flexibility of RevX communities is that while your RevX node is probably going to be hosted inside your firewall, your RevX community is made up of members and processes that may reside anywhere, on any RevX node.

The non-employee members of your community may be safely hosted on the RevX Portal Node, so they may enjoy the benefits and security of working within your communications network – without you having to set up and maintain a node for each of your suppliers.

All you need to do enter the unique email address of an outside supplier. Because the supplier is not a member of your domain, they will be automatically be set up as a user of the RevX Portal node, and as a member of your RevX community.

Of course, no matter if they are internal or external members, you control what rights any of your community members have – whether they can add new members, whether they can create or modify processes, etc., just as you control how processes and notifications are managed and escalated. With the RevX Portal Node, your outside partners are participating members in your community to the extent that makes sense for your business.

Communication between members of your community is handled over secure, industry-standard protocols such as HTTP, XML, and SSL.



With RevX, not only can you write automate processes and notification alerts to match your existing processes and systems, you can have the system work with your existing IT systems.

For example, let’s say you use an ERP system. What if you want to add new users automatically to your RevX community whenever you add them as a certain category of user to your ERP system, such as QA specialist. Using the non-published API, the RevX Professional Services team can write a process for that to automatically happen.

Or maybe you want your database to reflect the latest information from a section of your DB2 database. Using the RevX API we can write a “connector” where the data is updated as frequently as you want.


RevX Integration


n-Tiered Architecture

RevX’s RPM platform is an n-Tiered distributed system that is architected for scale, ease-of-use, and extensibility.  XML-based communication among RevX services extends through the gateway component to other network nodes.

Within a RevX node, the UI layer, or web front-end, is modularly designed so that future, non-browser device support will be provided as plug-ins. The front-end uses XML to communicate with the RPM process engine and any custom services needed for back-end integration.

The database interfaces are also modular, enabling database independence while maintaining performance with optimized physical designs.

Platform Independence

The node is designed for platform independence to provide maximum deployment flexibility. The web front end is built on industry standard Java servlet and XSL technologies that can be deployed on virtually any web server. Open standard UI protocols, HTML and DHTML, provide maximum user device support. Users need nothing more than a browser to interact with an RPM node.

Database abstraction services are also used to provide database independence. An abstraction layer  supports database connectors for Oracle 8x, Microsoft SQL Server, DB2, general ODBC and other databases. The connector architecture uses the database native call level interfaces to achieve maximum performance while providing transparent access to the core product functions. Database independence maximizes customer deployment flexibility.

Scalability nodes are designed for both small and large-scale implementations. A small example might be Microsoft Windows NT with IIS, SQL Server, and a local node all running 20 users on a single box. This type of configuration facilitates pilots, evaluations and prototyping.

The server component architecture is also designed to allow for large-scale implementations in a server farm environment. User session information maintained at the web servers can be load-balanced with off-the-shelf technology.

Behind the web server farm are RPM node services that can be deployed on servers in nearly any combination. The servers house services such as the process engines or the distributed gateway which are dynamically load balanced by the XML router  The XML router maintains awareness of all services in the local node and routes RXSP service requests to the best available service instance. This allows services to be deployed together, on separate servers in farms or in any combination based on the performance needs of the particular site.