Sunday, July 6, 2008



  Secure Transport of Transactions Over Any Network


SolAce Secure Wire Download Area

Join the open discussion listserve for SolAce Secure Wire users by sending e-mail to ssuser-subscribe@ivertex.com.

Please note that SolAce Secure Wire is a secure messaging server designed from scratch for the proposed HIPAA security rule. If you don't know what that means then you're probably not interested in this product. The final HIPAA security rule was "defanged" and in our opinion you really don't need this tool to meet the final letter of the law.

Binary Package
For a ready-to-run SolAce Secure Wire version 1.4 (9/27/2006), download a Windows installer or .zip file

Sample Configuration
We've included a sample PostOffice configuration under PostOffice/ss.xml. The ss.xml is the configuration for a single SolAce Secure Wire instance, and it can reside anywhere. We developed SolAce Secure Wire using Sun JDK 1.4.2. It has been tested on Windows & Linux with Java 1.4.2 and higher. versions.

SolAce Secure Wire is only 40 Java classes and 33 JSP files at current count. It is a very straightforward design. You can add timed and triggered adapters by implementing an interface with a single method on it. So jump right in, it's easy stuff! What's really amazing is that other firms sell this type of technology for $25,000 to $2,000,000+.

Source Package
For source code, which includes an Ant script to build the product, download this zip file and extract it. CVS access is not available yet.

A shortcut to run from source is just enter "make run" (or "ant run" if you have Ant in your path) at the top-level directory. It will compile, package everything into a package sub-directory (which is what the binary download is above), and run with the sample configuration file.

Important Note
We have included many required JAR files that we believe are safe to be distributed with a GPL product.

We did not include JDK 1.4's dt.jar, tools.jar, local_policy.jar, and US_export_policy.jar. You should locate these files from your JDK's lib and jre/lib/security folders, and put them in the SS/lib folder. If you don't want to copy them then you'll need to modify the classpath referenced in the SS/bin folder for at least dt.jar and tools.jar. These files are necessary for JSP compilation and strong encryption purposes.

Terminology
A PostOffice is what SolAce Secure Wire is hosting for you. As the owner of that SS instance, you can administer the PostOffice by logging into the web-based admin interface and changing any of the settings you want. You can also administer mailboxes. A Mailbox represents a remote entity for your PostOffice, and has an Inbound Channel and Outbound Channel with settings on both. Mailboxes can represent remote SolAce Secure Wire instances that push data to you, and you push data to them, or they can be remote clients that come pick up their data and expect you to store it for them.

Some commercial products use the same terms we do, and others use the terms Host and Trading Partner. They are the exact same thing.

Administration
The administration interface is accessible via a web browser. Once you get the product running it has a web listener running on port 9900 for HTTP, 9902 for HTTPS by default. So hit http://localhost:9900 and login as admin / admin to setup your SS instance and create an SSL self-signed cert. To setup two points, run SS instances on separate machines and point their outbound channels at each other with https://remote:9902/send.rpc. Anything with a .rpc suffix works for the URI (configurable via Servlets tab in admin interface).

You can also log in to the admin interface with a mailbox username/password. The settings are limited in this case, to allow your remote trading partners to administer some of their own settings. File upload/download is being added to this user area to allow pickup/drop-off of files via SSL only.

Protocol
The SolAce Secure Wire protocol is implemented in com.ivertex.listeners.SSHandler and com.ivertex.protocol.SSClient. It is XML-RPC over SSL using XML messages that contain the encrypted and signed payload. Signed and authenticated receipts are returned after decryption and signature verification has occurred. The protocol is conceptually very similar to IETF's AS2 protocol, though is it not compatible or similar to any protocol at the byte level. If you want to create your own protocol just create classes to mirror the two mentioned above, and add your own HTTP listener to be called alongside com.ivertex.listeners.RPCListener.

Crypto
We currently have an all-Java public/private key implementation for encryption and signatures, using BouncyCastle. It should be very easy to add PGP or GnuPG integration to this package instead of using our built-in crypto class. We have done this type of work for other products, but haven't applied it to the SolAce Secure Wire protocol yet because we wanted this product to be coded from scratch and thoroughly unique. If you want to take a stab at this we can help you get started in the right direction.

Logging
We are using Log4J for logging. We create a daily rolling log file at the PostOffice level, and a separate log for each Mailbox.

Data Access
All data access in the system goes through a singleton class named com.ivertex.config.Config. If you want to replace the configuration store with another persistence mechanism you need to start with this class and work your way through the value objects in the same package.

Testing
Everyone is interested in seeing the sustained throughput on products like this. We've benchmarked SolAce Secure Wire at over a million transactions in a day on an internal network with decent server-class hardware (dual P3 600Mhz & a single 1.8Ghz) setup in point-to-point fashion. The throughput gets much better when you have three or more points, as the load is distributed to the right machine instead of the typical hub-and-spoke topology where one machine gets the majority of the load. If you want to setup your own tests look at the QueueOutbound and LoopBack adapters. They can be setup to feed a constant message stream to measure network, memory, and CPU loads.

Future
Once this phase is solid we want to add workflow (Bossa perhaps) and a content management system or blogger (have looked at WebWork, SnipSnap, & JetSpeed so far) to make it easier to build:

  • Integration screens for back-end systems
  • Front-facing GUIs for your trading partners to use to share information
  • And whatever else you can think of

 

 
SolAce Secure Wire Menu
  Overview
  Features
  Screen Shots
  Prices
  Download
  News
 
SolAce Secure Wire Highlights
Reliable delivery, tamperproof and encrypted messages, and signed receipts proving message delivery to the originator of the message. Never lose an e-mail message or FTP transaction again.
Integrates seamlessly with almost all FTP servers, EDI gateways, and claims adjudication systems. Transports any type of file securely and reliably, not limited to HIPAA or EDI transactions.
No clearinghouse, no transaction fees, and no cost and complexity of a private network. The cost of your Internet connection is the only thing you pay.
Secure (SSL) web-based administration and remote mailbox access. No limit on connections.
Security features to foil hacker reconnaissance and attacks.
Open source and extensible to support custom delivery and processing adapters, at several points.

Are you using FTP and dial-up as your current EDI gateway solution? Save yourself!

Use SolAce Secure Wire For...
Groups - Setup secure channels between multiple medical offices to do secure file transfers.
Providers - Two-way, direct links to payers. Transmit directly and bypass all clearinghouses for the cost of your Internet connection!
Payers - Integrate with a low-cost adjudication system to avoid costly EAI/Gateway products and clearinghouse contracts. Provide a no-cost transmission option to your submitters!

Desktop Edition | Enterprise Edition | Hosted Edition | SolAce Secure Wire | Payer List