Re: Storing data periodically on remote server
- From: Arne Vajhøj <arne@xxxxxxxxxx>
- Date: Thu, 09 Oct 2008 22:29:10 -0400
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 shifts 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 bitch.
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
.
- References:
- Storing data periodically on remote server
- From: carmelo
- Re: Storing data periodically on remote server
- From: Peter D.
- Re: Storing data periodically on remote server
- From: Lew
- Storing data periodically on remote server
- Prev by Date: Re: Storing data periodically on remote server
- Next by Date: Re: Storing data periodically on remote server
- Previous by thread: Re: Storing data periodically on remote server
- Next by thread: Re: Storing data periodically on remote server
- Index(es):
Relevant Pages
|