WSO2, the open source SOA company, today announced the debut of WSO2 Data Services. The new WSO2 product lets database administrators (DBAs) expose data in minutes via a Web services application programming interface (API)—without programming. With WSO2 Data Services, DBAs and database programmers now can contribute to a company’s service-oriented architecture (SOA) by creating WS-* style Web services and REST-style Web resources based on enterprise data. The WSO2 Data Services solution allows users to enter queries and map them into services and operations. The simple user interface enables anyone with a knowledge of the industry-standard SQL language to quickly create powerful data services. Once the query or stored procedure has been exposed as a service, it can be accessed across the network as a service or Web resource.

Why not reuse Microsofts ADO.Net REST APIs? Why invent yet another (and more limited by the looks of it) REST API? Which tool sets are going to support this new REST API? I've been looking around for data services APIs and besides reinventing another one, I don't see a lot of options here.

Well whole idea of WSO2 Data services is not to provide REST API , that is just one feature of that. It provides easy way to expose your Database as a Web Service (with no line of programming code). Not only that it also provide features like exposing excel, or spread sheet as a Web Service. Deepal http://blogs.deepal.org

Billy There is no single REST API. The approach we take is to allow you to create your own REST API based on the data structure. This page http://wso2.org/blog/sumedha/4051 explains the model. Effectively you can define your own XML structure and your own mapping into the HTTP GET, PUT, POST, DELETE. So you can build a real REST model based on your own requirements. Paul

The new WSO2 product lets database administrators (DBAs) expose data in minutes via a Web services application programming interface (API)—without programming.

Hmm, fetching rows from an Oracle database using SOAP+SQL*Net must undoubtedly be a great idea even if I can't get it. It should be a follow-up of some best practice as putting SQL statements in HTTP query strings. Guido

Guido The model certainly is not about putting SQL statements in HTTP or SOAP. That would not be "Service Oriented". The model WSO2 DS enables is to create a real "Service" based on the specific data model you have. For example if you have a customer database you can create a Service that allows you to create customers, lookup customers, change addresses, etc. The SQL is not exposed to the clients. This article http://wso2.org/blog/sumedha/2573 explains it nicely. Paul Fremantle CTO, WSO2

Paul, How are WSO2 DS web services different than what you can create using Oracle alone? Brad

But With the Microsoft stuff, the schema of the data is derived from the data source and it's exposed as REST with JSON or REST with XML depending on the client. The API here is completely open as to what the XSD is and what the XML is, I could implement this on top of any data source, not just relational ones. Just wondering whats the value add here over this? Doesn't this do the same thing? (don't mean to play devils advocate here, just looking for the value).

Guido

The model certainly is not about putting SQL statements in HTTP or SOAP. That would not be "Service Oriented".

The model WSO2 DS enables is to create a real "Service" based on the specific data model you have. For example if you have a customer database you can create a Service that allows you to create customers, lookup customers, change addresses, etc. The SQL is not exposed to the clients.

This article http://wso2.org/blog/sumedha/2573 explains it nicely.

Paul Fremantle
CTO, WSO2

Well, the TSS initial post doesn't help too much. Anyway, for me, and I repeat for me, it doesn't change so much. In my understandings, it is much like a DAO-proxy over SOAP. What it seems you expose is a relational model not a domain model, with all the complications of relationship management wrt an OO approach. I always prefer to work with ORM for all the persistence related issues and distribute computing left for high level (business) services. IMHO data management might have a service granularity inappropriate for SOAP/CORBA/whatever. Please note that is much a matter of taste: I don't like to think at a domain model (mapped on a RDBMS) as pure data with behavior embedded in services. Other may prefer this approach and feel very comfortable with it. Guido

I think it's analogous to BEA Aqualogic Data Services, right?