Ian Grigg from Systemics and Erwin van der Koogh from Sun have come up with a design for a XML based format for making payments and otherwise interacting with various account based systems, such as GoldMoney and E-Gold.
See the Busy Developer's Guide to XML/X for a quick intro to the format.
I'm definitely very happy with the general layout and proposed functionality of XML/X. While XML/X itself doesn't define a transport system, Iang and Erwin suggest a simple XML in a HTTP POST request. I've been having a discussion with Ian about using SOAP instead. Ian's not convinced of the benefits of SOAP. I can understand his arguments, XML/X already handles most of what SOAP does and in a simpler way.
SOAP Requests can look extremely messy, thats for sure. But one of the great things about SOAP is that there is no a wide variety of systems that automagically handle the binding between XML and the code. It is also a lot easier to create client interfaces for just about any language.
So the result of this, is that I'm working on an implementation of XML/X on top of SOAP.
The first thing I did was to create a simple J2EE Application implentation of an imaginary gold backed currency provider. This consists of a bunch of EJB's the actual logic being handled by a bunch of Entity and Session Beans. I've then implemented all the major functions of the XML/X interface as a Session Bean.
The next thing I need to do is to create a SOAP binding ontop of this Session Bean. I'm using JBoss 3.0 for my J2EE stuff and will be using The Apache Group's Axis SOAP Implementation for SOAP binding.
Now JBOSS 3.0 claims to support Axis, but it also does claim that it's automatic support is very early and there is next to no documentation about it, so I guess my task over the next day or so is to play with it.
(Currently Listening to Minnie Ripperton's classic "Inside My Love" on ?uestlove's excellent compilation of classic R&B "Babies Makin' Babies", Sweet)
This entry was posted in the following Categories: Payment Systems
Will it be possible to run over a distributed network?
One of the problems that is hard to get around with a currency server is that it can be targetted by hostile government/tax/privacy_invaders and either subverted or shutdown.
I think it would be pretty cools if such a function could be distributed to avoid points of failure.
cya, Andrew...
Posted by: Andrew McMeikan on August 19, 2002 10:41 PMThe reasoning here as far as I understand it is simply to have a standardized API/Message interface ontop of Currency Providers.
These currency providers will generally run on traditional web servers, just like E-Gold and GoldMoney does now.
However you can then build p2p payment systems on top of that. Ian Grigg's WebFunds project does pretty much that, even though there still is a payment server involved in it somewhere.
Some of the layers I'm involved with could be extended to a distributed p2p kind of network, but deep down there still needs to be an issuing server such as GoldMoney.
-P
Posted by: Pelle on August 19, 2002 10:51 PM