Showing posts with label Data Access. Show all posts
Showing posts with label Data Access. Show all posts

Wednesday, November 5, 2008

SOA Approach to integration

I recently read this post on TSS, where someone claims REST is object-oriented while SOAP would be process-oriented. That's a funny way to compare these approaches, it is not false but SOAP can also be object-oriented if you want, and Data Services are all about that, the difference is that you can manage the level of granularity in data integration, you are not limited to encapsulate any "atomic resources" (whatever it means) with CRUD APIs.

SOA Approach to integration

I recently read this post on TSS, where someone claims REST is object-oriented while SOAP would be process-oriented. That's a funny way to compare these approaches, it is not false but SOAP can also be object-oriented if you want, and Data Services are all about that, the difference is that you can manage the level of granularity in data integration, you are not limited to encapsulate any "atomic resources" (whatever it means) with CRUD APIs.

Data Services at Microsoft TechEd EMEA 2008

DataDirect will be exhibiting at Microsoft Tech·Ed EMEA 2008, taking place at Barcelona's Centre Convencions Internaticional, 10 – 14 November 2008.

In addition, Solutions Architect John de Longa will present “Frontiers in Data Access” on Tuesday, 11 November 2008 from 14:50 to 15:10 in theatre two followed by a second presentation Wednesday, 12 November 2005 at 15:20.

In his presentation, “Frontiers in Data Access” John de Longa will offer technical insight and valuable advice for enterprise, system and data architects as well as application developers and managers. He will discuss how to improve the scalability and flexibility of data access strategies.

“As more organisations implement service-oriented architectures they find themselves with a multitude of business services that need to access enterprise data – too often data access issues are overlooked until they become a problem,” explains John de Longa. “I’ll be exploring the concept of data services as an emerging approach for addressing data challenges in SOA.”
Data services enhance flexibility and simplify application development by providing a consistent mechanism for accessing, integrating and updating enterprise data, regardless of where it is stored.

Data Services at Microsoft TechEd EMEA 2008

DataDirect will be exhibiting at Microsoft Tech·Ed EMEA 2008, taking place at Barcelona's Centre Convencions Internaticional, 10 – 14 November 2008.

In addition, Solutions Architect John de Longa will present “Frontiers in Data Access” on Tuesday, 11 November 2008 from 14:50 to 15:10 in theatre two followed by a second presentation Wednesday, 12 November 2005 at 15:20.

In his presentation, “Frontiers in Data Access” John de Longa will offer technical insight and valuable advice for enterprise, system and data architects as well as application developers and managers. He will discuss how to improve the scalability and flexibility of data access strategies.

“As more organisations implement service-oriented architectures they find themselves with a multitude of business services that need to access enterprise data – too often data access issues are overlooked until they become a problem,” explains John de Longa. “I’ll be exploring the concept of data services as an emerging approach for addressing data challenges in SOA.”
Data services enhance flexibility and simplify application development by providing a consistent mechanism for accessing, integrating and updating enterprise data, regardless of where it is stored.

LINQ to Entities and LINQ to SQL

Eventually Microsoft decided to focus on LINQ to Entities for the next .NET 4.0.
See the ADO.NET blog and this entry.

This is a great decision, because their Data Access offer was much more than confusing to users, with too many ways to access the same data and too much overlaps between their different technologies.

The good news is that Microsoft recognizes the importance of having an intermediate Business Model to integrate data. This is a great milestone for the whole software industry!

LINQ to Entities and LINQ to SQL

Eventually Microsoft decided to focus on LINQ to Entities for the next .NET 4.0.
See the ADO.NET blog and this entry.

This is a great decision, because their Data Access offer was much more than confusing to users, with too many ways to access the same data and too much overlaps between their different technologies.

The good news is that Microsoft recognizes the importance of having an intermediate Business Model to integrate data. This is a great milestone for the whole software industry!

Friday, October 10, 2008

New version of Granite Data Services

http://www.infoq.com/news/2008/10/GDS-110-release.
See also: http://www.graniteds.org and Documentation.

New version of Granite Data Services

http://www.infoq.com/news/2008/10/GDS-110-release.
See also: http://www.graniteds.org and Documentation.

WSO2 Data Services

WSO2 recently introduce its new version of Data Services. The big new improvment is the ability to aggregate data from multiple databases.
See http://www.ebizq.net/news/10368.html and http://blogs.zdnet.com/Gardner/?p=2741.
My personal opinion is that this tool is just useful to publish few stored procedures or queries over SOAP / REST. The limitations are important:
Only supports relational DBMS.
Integration model is quite limited (see their examples).
No intermediate, neutral business model in the middle.
No optimizations possible.
Administrator have to manually create the query, then deploy the data services, this simply does not scale.
There is no API at the client-side to smartly manage the results of the data services calls.
Curiously, they don't say anything about updates and transactions.
See discussion here: http://www.theserverside.com/news/thread.tss?thread_id=51002.
Anyway, it is good to have an open source entry-level product in our Data Services market.

WSO2 Data Services

WSO2 recently introduce its new version of Data Services. The big new improvment is the ability to aggregate data from multiple databases.
See http://www.ebizq.net/news/10368.html and http://blogs.zdnet.com/Gardner/?p=2741.
My personal opinion is that this tool is just useful to publish few stored procedures or queries over SOAP / REST. The limitations are important:
Only supports relational DBMS.
Integration model is quite limited (see their examples).
No intermediate, neutral business model in the middle.
No optimizations possible.
Administrator have to manually create the query, then deploy the data services, this simply does not scale.
There is no API at the client-side to smartly manage the results of the data services calls.
Curiously, they don't say anything about updates and transactions.
See discussion here: http://www.theserverside.com/news/thread.tss?thread_id=51002.
Anyway, it is good to have an open source entry-level product in our Data Services market.

Wednesday, September 3, 2008

Is database-as-a-service a good idea?

Seen this article by Jean-Jacques Dubray on InfoQ, related to this other article by Arnon Rotem who explains why Database-as-a-Service (DBaaS) is a bad idea:

  • It circumvents the whole idea about "Services" - there's no business logic

  • It makes for CRUD resources/services

  • It is exposing internal database structure or data rather than a thought-out contract

  • It encourages bypassing real services and going straight to their data

  • It creates a blob service (the data source)

  • It encourages minuscule half-services (the multiple "interfaces" of said blob) that disregard few of the fallacies of distributed computing

  • It is just client-server in sheep's clothing


To me, DBaaS is just a new way to access a database and it is far from Data Services (which are all about data integration, mapping, persistence & SOA). The most interesting benefits of a DBaaS are to offer a DB that you won't administrate. Conversely, it also raises some questions in terms of scalability and confidentiality.

Is database-as-a-service a good idea?

Seen this article by Jean-Jacques Dubray on InfoQ, related to this other article by Arnon Rotem who explains why Database-as-a-Service (DBaaS) is a bad idea:

  • It circumvents the whole idea about "Services" - there's no business logic

  • It makes for CRUD resources/services

  • It is exposing internal database structure or data rather than a thought-out contract

  • It encourages bypassing real services and going straight to their data

  • It creates a blob service (the data source)

  • It encourages minuscule half-services (the multiple "interfaces" of said blob) that disregard few of the fallacies of distributed computing

  • It is just client-server in sheep's clothing


To me, DBaaS is just a new way to access a database and it is far from Data Services (which are all about data integration, mapping, persistence & SOA). The most interesting benefits of a DBaaS are to offer a DB that you won't administrate. Conversely, it also raises some questions in terms of scalability and confidentiality.

The coming wave in Data Services

A good introduction to Data Services by John Goodson, VP and GM of DataDirect, as part of the last Data Services World event, last June in NY.

The coming wave in Data Services

A good introduction to Data Services by John Goodson, VP and GM of DataDirect, as part of the last Data Services World event, last June in NY.

YAODBMS: NeoDatis

Yet another ODBMS: NeoDatis.

I have no time to review its features, but it is so funny to see all these new ODBMS.

YAODBMS: NeoDatis

Yet another ODBMS: NeoDatis.

I have no time to review its features, but it is so funny to see all these new ODBMS.

Alternative to the Entity Framework?

NHibernate 2.0 arrived. It seems there is no support for LINQ yet, but it is on the roadmap a next major release (2.1).

It seems this blog frequently covers the differences between NHibernate and the Entity Framework:

Alternative to the Entity Framework?

NHibernate 2.0 arrived. It seems there is no support for LINQ yet, but it is on the roadmap a next major release (2.1).

It seems this blog frequently covers the differences between NHibernate and the Entity Framework:

The need for fetch plans

As described in this article there is a strong need for fetch plans is JPA. Some people, even within the JPA expert group, seem to think there is no need for a specific API for fetch plans, they could be covered by criteria APIs. I personnaly think that a fetch plan is not a criteria or a filter, it is something related but different. Regarding this feature, data access technologies coming from the JDO world have some advantages, as this feature has been discussed with the JDO expert group since a long time.

Obviously, fetch plans are even more important when dealing with a disconnected data access model, like in Data Services. Some partial reconnection could be allowed when relationships are unknown during navigation, but current network technologies certainly cannot support full lazy loading over the Internet.

The need for fetch plans

As described in this article there is a strong need for fetch plans is JPA. Some people, even within the JPA expert group, seem to think there is no need for a specific API for fetch plans, they could be covered by criteria APIs. I personnaly think that a fetch plan is not a criteria or a filter, it is something related but different. Regarding this feature, data access technologies coming from the JDO world have some advantages, as this feature has been discussed with the JDO expert group since a long time.

Obviously, fetch plans are even more important when dealing with a disconnected data access model, like in Data Services. Some partial reconnection could be allowed when relationships are unknown during navigation, but current network technologies certainly cannot support full lazy loading over the Internet.