CODEWITHSUNDEEP
web-services
user2394774
user2394774

Reputation: 1

How can a web service talk to the server without accessing the server database?

I need to design a webservice for a data collection service - and the requirement is that the webservice should not access the database directly.

The web service will talk to the data collection service which in turn will access the database. So is HTTP the only option for web services to talk to the data collection service? But the data collection service is yet to be developed - is there a design that should be followed for the web service to be able to talk to this service? I want to make sure that the data collection service is implemented properly so that I can do my part of the web services without too many hassles.

Upvotes: 0

Views: 98

Answers (2)

David
David

Reputation: 218960

Think of the "web service" as any application in this case. The code which accesses the "data collection service" should work in any application, after all.

The "data collection service" is an external dependency to the application. As such, it should be abstracted behind a service facade. An interface, for example. (I'm going to use C# in my example, since I'm most familiar with that.) Something like this:

public interface IDataCollectionService
{
    void CollectData(SomeDataDTO data);
}

At this point, all code which uses the data collection service should use this interface type. Until the data collection service is developed, you can use a mock data collection service. Any in-memory implementation with just enough functionality to keep you going would work. For example:

public class MockDataCollectionService : IDataCollectionService
{
    public void CollectData(SomeDataDTO data)
    {
        // do nothing
    }
}

This implementation would have no side-effects, throw no errors, and just assume that everything in the external dependency worked as expected. You can edit/expand this mock to result in error conditions, etc.

(Note that I'm kind of using the word "mock" is a more generic way than purely unit testing terms. This happens a lot in the industry, actually. For your unit tests themselves, you could use any mocking library to create an actual unit test mock by using the above interface.)

This is all just an example, and how you structure it is entirely up to you. The point is that, as an external dependency, all interactions with the data collection service are behind a facade. Then, when that service is developed, it won't really matter what protocols and standards it uses. When you create a new DataCollectionService class which implements the interface, all of the code for using those protocols and standards would be encapsulated within that class. The rest of the project won't know or care the difference.

Then, when that implementation is ready, you can just swap it out with the "mock" implementation and test the system without having changed any other code in your application. If, at a later time, it's decided that the protocols need to change again, the only thing you'd need to change (or create a new one of) is that one class which implements the interface.

Indeed, if you ever are granted permission to access the database, all that would need to change is to again build a new implementation of that interface. Essentially, whether you can or can not access the database is just as immaterial as what protocols are being used. The architecture of the software abstracts it, so that the architecture of the infrastructure has as little impact as possible.

Upvotes: 1

Robert Harvey
Robert Harvey

Reputation: 180858

You can create a mock object that mimics the data collection service, until the actual service is completed. The mock object can double as a testing tool while you create your unit tests.

Upvotes: 0

Related Questions