Re: Storing data periodically on remote server

Lew wrote:
> Peter D. wrote:
>> I don't know if connecting to the DB directly is a good idea. I would
>> recommend creating a web service to accept the data instead. The
>> client will connect to the web service and send the info. The server
>> side web service will then connect to the DB and do what it needs to
>> do.
>>
>> With a web service you can even give your clients the option of coding
>> their own solutions with any language. Also, it gives you free reign
>> on your DB server since the web service will abstract it from the
>> users. If you want to change DBMS you just need to modify the web
>> service and not every single client.
>>
>> I think providing a standard web service interface is the way to go.
> 
> I started reading this dubiously, but came around as I pondered.

> There definitely is a learning curve, although Axis at least tries to 
> make the entry barrier quite low.  The benefit of thinking of your 
> system as a group of services is incalculable.  Never mind the "web" 
> part, the cooperating-service model is good to know.
> 
> While 100 clients pulsing once every ten seconds is not actually a very 
> demanding scenario, it still benefits from a web-service architecture, 
> properly constructed.  I don't even think it's much harder to conceive 
> than a more monolithic local app would be.
 >
> For example, Peter's suggested data-delivery service would be quite 
> monomaniacal.  It would understand the data needs, in terms of the 
> problem domain of course, but only as relevant data.  It wouldn't care 
> what the client code logic does with that data.  Just concentrate on how

> to get to the data store and construct the desired response.  The 
> clients would remain ignorant of the dirty details - as Peter says, they

> have been abstracted.
> 
> Application development ****fts to a mentality of pulling needed action 
> or information from services that are lying around awaiting activation.
> 
> Web services are a relatively easy way to get into service architecture,

> not only as a programmer but in that you can deploy on as little as
Tomcat.
> 
> Deployment turns out to be the *****.

Exposing data access layer as services is a well known anti-pattern
in SOA.

You should expose the business logic as services.

There may not be much business logic in this case, so it is more
a matter of English than of Java.

Arne