Hi Ray, I'm approaching a point where we should take a decision whether to implement the solution using a web service or take some other way. First things first - I have never ever created one and haven't even seen one but from what I've seen on the Net and in the docs shouldn't be too much hassle. Let me explain what's it about - generally it's the healthcare industry, I'm working in a medical lab that provides services both to patients themselves and medical institutions. We're constantly searching a way to shift some of the weight to other partners in the business - both to free up our resources and try to evade mistakes that are done during the sample collection and test ordering. Hardly any of the patients you talk to can tell you which test is checking on what. We're happy when they arrive with a piece of paper stating "this, this and this", but in 90% of cases it's hardly readable and to be frank... I want to eliminate those darn papers. After all we're in the 21st century. Bottom line, I'm thinking of implementing a few web services that will provide a way for a doctor himself to order the tests for the patient and our part would be to only collect either the sample or to draw blood directly, label the tube and put it on the analyzer. That's all. After that, the doctor can check on the status by the means of the other web service or his palm or whatever if he's out of the office. BTW palms and web services can cooperate...? So my question basically is this - should I stick to web services or search for some other solution?
Handhelds can use web services (see kSOAP), but if the application is for internal use only, the benefits of web services might not be that significant compared to a faster binary protocol. Having said that, here's something to think about:
The back-end functionality is implemented on top of a J2EE application server and exposed to clients via web services (using JAX-RPC, for example)
The "ground" staff accesses the back-end functionality through a web application (which invokes the web services), or through a desktop application (Swing or .NET invoking the web services)
The "mobile" staff accesses the back-end functionality through a "gateway" web application, which talks a binary format with the handheld and invokes the back-end web services to provide the functionality
It looks like your healthcare case is a good candidate for web services because: 1. there are many trading partners involved (medical labs, doctors) 2. point-to-point interfaces or traditional EAI will be an integration issue due to re-usability, portability, and interoperability 3. cost of integration is a key business driver I heard that there are some interest in the healthcare industry, e.g. http://www.ebizq.net/topics/healthcare/features/1546.html, Gorilla Logic has produced a RFID-based web services for the healthcare industry and connect them using HIPPA. Lasse has already suggested kSOAP as an infrastructure component to enable your Palm or PocketPC to "speak in SOAP". Also refer to my book ch 9, p. 486 section 9.2.2 for more details of wireless web services.
Free chapter summary/binaries of J2EE Platform Web Services can be found at <a href="http://authors.phptr.com/lai/." target="_blank" rel="nofollow">http://authors.phptr.com/lai/.</a><br />Get your copy from <a href="http://www.amazon.com." target="_blank" rel="nofollow">www.amazon.com.</a>
Is there any reason to use webServices over servlets in an internal environment?? i.e. our webserver is not open to the world, but to a very small client base. We get xml request, process it, then build xmlResponse. Is there any reason to go one more step and make it a webService?
"No one appreciates the very special genius of your conversation as the dog does."
Originally posted by John Dunn: Is there any reason to go one more step and make it a webService?
I think that making it a web service is a good idea, not (only?) because you will follow the hype and be cool, but to acquire more clients. I bet that when you say to your clients we have a web service, they auto. think that integration is without problems, and don't need to "learn" your interface, which is not the case when u have ur custom xml interface. (Even if the messages look indeed like they would if they were web services, but are not wrapped in a SOAP message.). It might as well make new employees feel comfortable with it, and if they have any web services exp. it would look familiar to them. U can also use it as sells speech to current clients, by saying WE R SO COOL THAT we moved to web services.