The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

SOAP, Web Services, applicable ?

Hi

I need to sync data over a network between a PDA and a remote database hosted on a PC. Some suggest that it is a good idea to create Web Services and exchange SOAP messages.

Now what does that really buy me, apart from the thrill of having my data squeezed in between XML tags?

I'm afraid of:
- XML will inflate the volume of data to transfer, syncs will be lengthy over a GPRS connection
- call me stupid, but it all seems extremely complicated; first I need to tell my customer to install Tomcat, Java, some kind of XML parser, this and that, and then I need to figure out how the whole thing works and navigate all the acronyms. Seems pretty heavy just to pull some bytes from a wire.

How about a simple cgi script in C that would read my data records encoded in my own cute little binary format?

But then again, everyone is excited about that SOAP stuff so there must be something there, no?

Is the learning curve as steep as it seems?

Any thoughts? (or links to documentation ?)
Thanks
Parisian developer ISO cute geek girl
Wednesday, July 27, 2005
 
 
IMO, web services are useful only in a B2B context. XML over HTTP may be enough to do the trick for you. But then you're right, you need to compress for less traffic and that takes CPU cycles which are expensive on a PDA. Hmmm ... And then there is supporting the whole damn system: web container, web app, etc. All this may be indeed an overkill and you may be better off with writing your own data transfer code, which of course you'll need to support and maintain.

I guess you have to look at the overall efforts to develop and use/maintain the whole system. Whichever proves more efficient on the long run is your answer.

You need to do the $$$ math. It's all about profits.
Dino Send private email
Wednesday, July 27, 2005
 
 
Seems overkill to me. Just build an EXE to run on the client host to which the PDA is connected, and either upload the changes to the database file or by connecting to the DBMS server.
Parisian developer ISO cute geek guy (and it's a bit hot here)
Wednesday, July 27, 2005
 
 
>
> Parisian developer ISO cute geek
> guy (and it's a bit hot >here)
>

Hey ya wanna get together & discuss various compression methods?
Parisian developer ISO cute geek girl
Wednesday, July 27, 2005
 
 
First of all, you two get a room! :-) Jokes aside, I too think SAOP wouldn't do it: too verbose, too heavy ( http://www.artima.com/forums/flat.jsp?forum=106&thread=4846 ). Did you check out SyncML? Seems it's the 'industry standard" for synchronizing data between mobile devices and the rest of the world.
Emil Kirschner
Thursday, July 28, 2005
 
 
You would use webservices because it would make things easier (transport, authentication, failiure handeling, scaling  ...) because of the (tool-)support for it. If that (for whatever reason) does not apply to yor scenario, then it's just overhead. Build on another RPC, messaging, wathever infrastructure or invent your own.
Just me (Sir to you) Send private email
Thursday, July 28, 2005
 
 
Parisian developer ISO cute geek girl > Hey ya wanna get together & discuss various compression methods?

I don't feel like talking in that kind of weather ;-)
Parisian developer ISO cute geek guy (I should get AC)
Thursday, July 28, 2005
 
 
Thanks to all who replied.
Yes SyncML is definitely on my list of things to look at.
Parisian developer ISO cute geek girl
Thursday, July 28, 2005
 
 
I had a similar project 5 years ago. Except it was WinCE. I was surprised when a developer recommended using SOAP. I had considered it but thought it would be too bloated. But it wasn't. No compression, no nothing. This was Java on a turn-of-the-century WinCE machine, and the connection was 16bps.

The main obstacle in remote messeging is network latency not message size or serialization/deserialization.

The recommendation is don't assume, and dont' optimize prematurely. Try out SOAP on a minimal prototype. If it works, good. If it's a little slow, compress. If that doesn't work, proceed from there.
slava Send private email
Thursday, July 28, 2005
 
 
Q1. "XML will inflate..."?
A1. Yes.
A1a. This is a trade-off between performance, efficiency, complience to standards, extensibility (and bunch of other buzz words). Depends on data you need. For example, if you can use HL7 for medical info is can be a plus for "potential interoperability" with other medical applications. Question is - "Can you benefit from it?"

Q2. "it seems extremely complicated... to pull some bytes from a wire..."
A2. Yes.
A2a. If you can go for a simple "status code" situation - go for it. But if you think "extensibility" - think again. My experience tells you can _always_ combine simple format for simple situations and complex for complex situations - some time spent on system design really worth _a lot_ of maintenance effort. Same experience tells there is almost zero architectures (read "architects"), that can use it.

Q3. "How about a simple cgi script in C that would read my data records encoded in my own cute little binary format? ... Is the learning curve as steep as it seems?"
A3. Good; No.
A3a. Trust what you (or your developers) are good at.
A3b learning distance beween "Pure C CGI" and "Tomcat J2EE" entirely depends on the person. Again, you have a choice between doing it fast and efficient against doing it "evolveable".

Q4. Any thoughts?
A4. A lot.E.g. - Do you think about using compact .Net and J2EE interoperability and a bunch of other quesitons ... You described your task pretty vague; it suits "la belle geek girl de Paris", but it's a little complicated to help you with someone's experience. Anyway - sounds like a very, very interesting task. Have fun with it and keep us updated.
accidently drunk Send private email
Thursday, July 28, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz