wso2 data source server - creating a data layer for a new service

Question

It seems that most of the WSO2 DSS documentation is focused around the use case of exposing existing data sources.

When creating a new service from scratch, would you implement the new CRUD data access layer using DSS, or would you would implement the data access layer using the standard java based approaches (E.g. spring, hibernate, etc.)? What are the pros and cons of both approaches (DSS vs Java) for new services?

Answer 1

IMO, it depends on where and when this new service is developed and get hosted. If you're a one man shop dealing with one application, there is no difference going down either path. At development time, you know the system in and out, you know where your data access code should be written, what sort of data you're transferring between the DB and the application and where this information is getting used in your application.

This is one reason why some people tend not to touch anything with web services even with a ten foot pole. You're introducing additional overhead and complexity and not being able to justify why would you possibly need it.

Let's say you work in place where there are multitude of developers involved with developing all sorts of applications which at some point in time will have the need of talking to each other and want to share information. In a situation like this, you probably have internal policies to mandate which library versions you can use to build your data access logic and other business functionality in your application. So, in an environment like this, when you introduce a new service, it would be wise to think in terms of possible service reuse. When you develop a new service and slap a CRUD interface on top of your DB tables, when your data model expand you'll end up with a lot of services. Then for a new application when you're reusing these services one operation might involve doing several service invocations which might yield sub par performance. So you'll end up having another composite service or two which does several of these DB calls through JDBC for performance. Then if you do that, soon you'll end up having duplicated services.

Contrasting this situation with standard Java based approach, when you're introducing a new service which will affect several of your existing systems, you need to write code for all those system to make use of your new service. If those systems are written using the same version of libraries you're using, say, Hibernate then your life becomes somewhat easier. If those systems are written using different people in different ways again life becomes complex. Here, doing a web service call probably is easier.