This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am fairly new to SOA/Web services and i am currently been exposed to j2ee world. But i would like some advice about a new project i am about the start on.
Currently we have a legacy corba server that recieves updates notification from a sybase database (do not know as yet how it does that as its a proprietry server) and sends this to a web service application client that sits an Artix Enterprise Service Bus(IONA Product).
Now the Corba server is to be removed as it will no longer be supported. So i have been given the task to rewrite its functionality using this Artix ESB of which corba is supported. So i could use corba if i wanted to. Artix also heavyly supports XML so I could maybe use SOAP/xml/rpc/http/corba. It also supports JMS. I have proposed to have on thread just getting this notification and other thread sending these notification to any connected clients. So as to remove any bottleneck. I suppose my question is which protocol do you deem approraite for a server that that will fairly busy and why?.
XML over HTTP is the most universal protocol, or lowest common denominator if you prefer. You can implement your server with a servlet which gives you all the threading and scalability benefits of a servlet container with very little effort. Plenty of tools will generate the public interface for you so you never have to see XML or WSDL.
Seems to me that XML messages via JMS would have the advantage that data will not be lost if the target application is currently unresponsive. The "publish - subscribe" could handle multiple clients. Bill