I have a system to design - I'm bound by some NDA's, but I'm considering a few higher level design strategies and value the opinions on this forum.
Because I can't give specific examples, lets just say you're the customer of a retail store, and you walk up to a PC. It has a java application running on it that catalogues the contents of the retail store. You make your selections, and then choose to buy them. The product selection should be database driven, and while some caching can be done, the client should approach the server regularly to validate it has a current version, and also the server must verify with the database somewhat regularly to make sure there are no discrepencies.
Once you submit your order, a "message" will be sent to the warehouse, in which they will collect the required widgets and get them ready for you. When the warehouse portion is done, a "message" must be sent to a runner - a store employee that will get your items from the warehouse and then deliver them to you.
Also, at any time, you can send a "message" to the runner asking for help - although it doesn't add much complexity, it does add some bandwidth.
Lets say I have 70 clients on a regular basis, 15 runners, and 10 warehouse people. Each "message" must be persisted.
From a higher level architecture overview, what do you think about the following:
Using sockets and serialization to communicate data (bandwidth, overhead concerns??)
Using a SOAP XML based messaging over sockets? Over http?
I'd look into a messaging product (IBM's WebSphere MQ and Fiorano MQ are two I've used) with persistent messaging, also known as "assured delivery". The messaging middleware can store and forward messages if the receiver is down, unlike sockets that just fail to connect. The JMS APIs in Java make it easy to use messaging in a product-independent way.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi