Wednesday, January 23, 2008

Xcalia mentioned in MS PR about VS 2008 / .Net 3.5

End of 2007, we have been pleased to see Xcalia mentioned in the official announcement of Visual Studio 2008 and .Net 3.5.

They also kindly release a nice Case Study about our Lab-2-Lab relationship around LinQ in 2007. During the whole year of 2007 we really enjoyed working with the Microsoft Visual Studio 2008 R&D team as part of the TAP program. The result is a very nice use of LinQ from our Xcalia DAS, as an alternate QL.

Xcalia mentioned in MS PR about VS 2008 / .Net 3.5

End of 2007, we have been pleased to see Xcalia mentioned in the official announcement of Visual Studio 2008 and .Net 3.5.

They also kindly release a nice Case Study about our Lab-2-Lab relationship around LinQ in 2007. During the whole year of 2007 we really enjoyed working with the Microsoft Visual Studio 2008 R&D team as part of the TAP program. The result is a very nice use of LinQ from our Xcalia DAS, as an alternate QL.

Xcalia & Microsoft about interop

Microsoft France is running regular technical sessions about Interoperability.

Last December we had a session about Xcalia DAS as a generic solution for Data Access, when users have both Java and .Net client applications.

During this session Steve Sfartz introduces the new features of LinQ within Visual Studio 2008, the upcoming Entity Metadata Framework and the Microsoft vision about Data Services. He also discussed the positioning of Xcalia DAS versus Microsoft solutions.

See videos here... (all in French, sorry).

Xcalia & Microsoft about interop

Microsoft France is running regular technical sessions about Interoperability.

Last December we had a session about Xcalia DAS as a generic solution for Data Access, when users have both Java and .Net client applications.

During this session Steve Sfartz introduces the new features of LinQ within Visual Studio 2008, the upcoming Entity Metadata Framework and the Microsoft vision about Data Services. He also discussed the positioning of Xcalia DAS versus Microsoft solutions.

See videos here... (all in French, sorry).

Monday, January 21, 2008

XQuery

TheServerSide mentions a series of tutorials about XQuery and XQJ (XQuery Java interface).

I've never really believed into XML as a replacement storage format for "real" (e.g "serious") databases. However, I believe into XML as a new interface around databases, or as a convenient local storage when requirements are limited (no transactions, single-user, lo logging, no locking) for pervasive computing or long-running transactions for instance.

The same way, I've never bought the concept of an XML server or XML programming. I don't see XML as being simpler than Java or more readable.

Finally, I used to be reluctant regarding data integration solutions aggregating everything through XML. This could be OK for non transactional, read-only applications but not for highly transactional applications.

But when it comes to Data Services, e.g. integrating, mapping, transforming and publishing databases and data services as services then you'll probably need XML somewhere. The SDO 2 marshalling is built on top of XML. From a DAS perspective there is now the question of which Query Language to be adopted. It could be SQL, an object query language (JPAQL, JDOQL, OQL, OSQL...), it could be a programmatic QL or even LinQ.

Within the Xcalia DAS, we currently support JDOQL, SQL and LinQ (only in .Net). We also intend to support JPAQL, as soon as we will support JPA 2 in XIC. But it becomes clear, as the SDO datagraph is serialized in XML, that XQuery is a good candidate for an alternate QL. This is an option we will certainly investigate in 2008.

XQuery

TheServerSide mentions a series of tutorials about XQuery and XQJ (XQuery Java interface).

I've never really believed into XML as a replacement storage format for "real" (e.g "serious") databases. However, I believe into XML as a new interface around databases, or as a convenient local storage when requirements are limited (no transactions, single-user, lo logging, no locking) for pervasive computing or long-running transactions for instance.

The same way, I've never bought the concept of an XML server or XML programming. I don't see XML as being simpler than Java or more readable.

Finally, I used to be reluctant regarding data integration solutions aggregating everything through XML. This could be OK for non transactional, read-only applications but not for highly transactional applications.

But when it comes to Data Services, e.g. integrating, mapping, transforming and publishing databases and data services as services then you'll probably need XML somewhere. The SDO 2 marshalling is built on top of XML. From a DAS perspective there is now the question of which Query Language to be adopted. It could be SQL, an object query language (JPAQL, JDOQL, OQL, OSQL...), it could be a programmatic QL or even LinQ.

Within the Xcalia DAS, we currently support JDOQL, SQL and LinQ (only in .Net). We also intend to support JPAQL, as soon as we will support JPA 2 in XIC. But it becomes clear, as the SDO datagraph is serialized in XML, that XQuery is a good candidate for an alternate QL. This is an option we will certainly investigate in 2008.

Thursday, January 17, 2008

Persistence as a Service

In this blog entry, Nati Shalom from GigaSpaces introduces his vision of an in-memory cache which would become the main persistence interface for applications.

You then just need to persist that cache, somewhere using some DB APIs. This process can be done asynchronously, in background.

Obviously, we also need to have some database functionalities around the cache, at least:

  • Transaction management.

  • Locking mechanisms for concurrency.

  • Query engine.

  • Metamodel management.


Questions:

  • What about crash recovery?

    • The cache also requires some kind of logging, like in a database.



  • What about triggers, stored procedures?

    • Are they managed by the cache, by applications?



  • What about security?

    • Is that managed by the cache or somewhere else. I tend to agree that security must be managed externally through a dedicated component, and database is definitley not the right place to define security policies.



  • What about Referential Integrity?

    • Is that managed by the cache or only by the applications?



  • What about bulk load and bulk updates?

  • What about huge volume of data (hundreds of GB and more)?

  • What is the best API between the application and the cache?

    • SQL?

    • POJO detachment?

    • SDO?

    • Something else?



  • Database engines have built-in caches integrated.

    • In this case, why accessing a distributed cache would me significantly much faster than accessing a distributed database engine?

    • I remember an old article from TimesTen in the 90's where they said it is more efficient because there is no huge OS code (IO, thread management, etc.) in the cache system, and thus this memory mangement by itself is more efficient.




I really think we need some kind of specific, optimized protocols between the applications and the cache if we want to make this kind of new attractive architectures scalable. Otherwise updating the cache won't be much more efficient than talking to the database server itself.

It would be definitely interesting to think and experiment about the integration of such in-memory persistence interface and a DAS.

Persistence as a Service

In this blog entry, Nati Shalom from GigaSpaces introduces his vision of an in-memory cache which would become the main persistence interface for applications.

You then just need to persist that cache, somewhere using some DB APIs. This process can be done asynchronously, in background.

Obviously, we also need to have some database functionalities around the cache, at least:

  • Transaction management.

  • Locking mechanisms for concurrency.

  • Query engine.

  • Metamodel management.


Questions:

  • What about crash recovery?

    • The cache also requires some kind of logging, like in a database.



  • What about triggers, stored procedures?

    • Are they managed by the cache, by applications?



  • What about security?

    • Is that managed by the cache or somewhere else. I tend to agree that security must be managed externally through a dedicated component, and database is definitley not the right place to define security policies.



  • What about Referential Integrity?

    • Is that managed by the cache or only by the applications?



  • What about bulk load and bulk updates?

  • What about huge volume of data (hundreds of GB and more)?

  • What is the best API between the application and the cache?

    • SQL?

    • POJO detachment?

    • SDO?

    • Something else?



  • Database engines have built-in caches integrated.

    • In this case, why accessing a distributed cache would me significantly much faster than accessing a distributed database engine?

    • I remember an old article from TimesTen in the 90's where they said it is more efficient because there is no huge OS code (IO, thread management, etc.) in the cache system, and thus this memory mangement by itself is more efficient.




I really think we need some kind of specific, optimized protocols between the applications and the cache if we want to make this kind of new attractive architectures scalable. Otherwise updating the cache won't be much more efficient than talking to the database server itself.

It would be definitely interesting to think and experiment about the integration of such in-memory persistence interface and a DAS.

Wednesday, January 16, 2008

Oracle bought BEA today

What will be the impact on the SDO / DAS specifications and Data Access in SOA in general? See here for details.

Sun also announced they bought MySQL. Same questions. This one is a little bit more difficult to understand. It seems to me be it will take a very long time to make this investment profitable. See a possible positive explanation here, and the point of view of Rod Johnson. At a first glance this is a good news for the open source model, but at the end what will be the impact on RedHat? GlassFish + MySQL could be a killer. Same question about the relationship between Sun and Oracle. Could GlassFish + MySQL be a valid low cost alternative to WebLogic + Oracle?

Maybe J. Schwarz had the good vision with his open source strategy and Solaris + Java + GlassFish + NetBeans + MYSQL might become the best open source stack?

Then, what will be the next acquisitions? SAG? SAP? RedHat?

At the end, maybe we'll have only ORCL, IBM and MSFT remaining in the software industry. Is it still possible to be a pure player in this industry? Who will lead innovation in the future? Is that consolidation a side-effect of the open source pressure?

Oracle bought BEA today

What will be the impact on the SDO / DAS specifications and Data Access in SOA in general? See here for details.

Sun also announced they bought MySQL. Same questions. This one is a little bit more difficult to understand. It seems to me be it will take a very long time to make this investment profitable. See a possible positive explanation here, and the point of view of Rod Johnson. At a first glance this is a good news for the open source model, but at the end what will be the impact on RedHat? GlassFish + MySQL could be a killer. Same question about the relationship between Sun and Oracle. Could GlassFish + MySQL be a valid low cost alternative to WebLogic + Oracle?

Maybe J. Schwarz had the good vision with his open source strategy and Solaris + Java + GlassFish + NetBeans + MYSQL might become the best open source stack?

Then, what will be the next acquisitions? SAG? SAP? RedHat?

At the end, maybe we'll have only ORCL, IBM and MSFT remaining in the software industry. Is it still possible to be a pure player in this industry? Who will lead innovation in the future? Is that consolidation a side-effect of the open source pressure?

Defining a Data Grid

Seen on TheServerSide a Cameron Purdy's blog entry, former CEO of Tangosol, another good caching technology, acquired by Oracle last year.

Cameron's blog.

I used to have problems understanding the notion Data Grid itself, beyond the hype. To me it raises as many questions as answers. I recently changed my mind a little bit, and I will later explain in this blog what could be a grid of Data Access Services (DAS).

Defining a Data Grid

Seen on TheServerSide a Cameron Purdy's blog entry, former CEO of Tangosol, another good caching technology, acquired by Oracle last year.

Cameron's blog.

I used to have problems understanding the notion Data Grid itself, beyond the hype. To me it raises as many questions as answers. I recently changed my mind a little bit, and I will later explain in this blog what could be a grid of Data Access Services (DAS).

Querying GigaSpaces with JDBC

Interesting article seen on TheServerSide about Querying Gigaspaces with JDBC.

GigaSpaces has a very compelling caching technology. And caching is an extremely important component of a Data Acces Layer in SOA.

Querying GigaSpaces with JDBC

Interesting article seen on TheServerSide about Querying Gigaspaces with JDBC.

GigaSpaces has a very compelling caching technology. And caching is an extremely important component of a Data Acces Layer in SOA.

Tuesday, January 15, 2008

POJOs and SDO / DAS relationships

I have seen some early implementations of the DAS relying on POJOs persistence (JPA, JDO). Conversely, we could imagine JPA implementation built on top of a DAS. Interesting to see that both approaches have their own benefits.

At Xcalia, our first implementation of the DAS was heavily relying on our POJO persistence mechanisms. We are currenlty working on decoupling these 2 technologies and we now tend to consider both SDO and POJOs are just two kind of consumers, interfaces, APIs of our internal neutral Data Access layers.

Obviously, we will preserve the current bridge between the POJO and SDO worlds: we already publish some detachSDO() / attachSDO() APIs which complement the simple POJO attach() / detach() ones.

Some members of the SDO expert group see SDO as an aspect of POJOs, exactly as JAXB would be another aspect.

POJOs and SDO / DAS relationships

I have seen some early implementations of the DAS relying on POJOs persistence (JPA, JDO). Conversely, we could imagine JPA implementation built on top of a DAS. Interesting to see that both approaches have their own benefits.

At Xcalia, our first implementation of the DAS was heavily relying on our POJO persistence mechanisms. We are currenlty working on decoupling these 2 technologies and we now tend to consider both SDO and POJOs are just two kind of consumers, interfaces, APIs of our internal neutral Data Access layers.

Obviously, we will preserve the current bridge between the POJO and SDO worlds: we already publish some detachSDO() / attachSDO() APIs which complement the simple POJO attach() / detach() ones.

Some members of the SDO expert group see SDO as an aspect of POJOs, exactly as JAXB would be another aspect.

Comparing some persistence frameworks

This article on InfoQ links to this comparison between frameworks.

It always seemed odd to me to compare 2 standards (EJB CMP, JPA) and 2 products (Hibernate, Toplink). JDO is not in the list, which means this comparison is not really neutral and at least not technically oriented. I don't know what was the goal of the author, but the result seems a little bit confusing to me.

Comparing some persistence frameworks

This article on InfoQ links to this comparison between frameworks.

It always seemed odd to me to compare 2 standards (EJB CMP, JPA) and 2 products (Hibernate, Toplink). JDO is not in the list, which means this comparison is not really neutral and at least not technically oriented. I don't know what was the goal of the author, but the result seems a little bit confusing to me.

Jimmy Nilsson on LINQ to SQL

This articles on InfoQ links to a 10 minutes JAOO interview.

Summary
In this interview, Jimmy focuses on LINQ to SQL and ORM. Jimmy has tried to create a similar technology to LINQ to SQL in the past, but without similar results. While LINQ to SQL is a step in the right direction, .NET still lags behind other programming languages in object-relational mapping capabilities.

Bio
Jimmy Nilsson is co-founder and CEO of the Swedish consulting company factor10. He has written numerous technical articles and two books, including 'Applying Domain-Driven Design and Patterns'. He has also been training and speaking at conferences, but above everything else, in his own words, he is a developer with twenty years of experience. Visit Jimmy's blog at http://JimmyNilsson.com/blog/.

Jimmy Nilsson on LINQ to SQL

This articles on InfoQ links to a 10 minutes JAOO interview.

Summary
In this interview, Jimmy focuses on LINQ to SQL and ORM. Jimmy has tried to create a similar technology to LINQ to SQL in the past, but without similar results. While LINQ to SQL is a step in the right direction, .NET still lags behind other programming languages in object-relational mapping capabilities.

Bio
Jimmy Nilsson is co-founder and CEO of the Swedish consulting company factor10. He has written numerous technical articles and two books, including 'Applying Domain-Driven Design and Patterns'. He has also been training and speaking at conferences, but above everything else, in his own words, he is a developer with twenty years of experience. Visit Jimmy's blog at http://JimmyNilsson.com/blog/.

New Query Languages

For sure ODBMS did a lot to standardized advanced QL. Hibernate HQL itself has been inspired by ODMG's OQL as JDOQL or JPAQL as well.

The guys at DB4O are also doing a good job and investigate new approaches. LinQ from Microsoft is alternate approach of statically checked queries.

Having an object-capable Query Language is a pre-requesite to manipulate Business Models.

This article, seen on InfoQ introduces the Objectivity Object Query Language.

New Query Languages

For sure ODBMS did a lot to standardized advanced QL. Hibernate HQL itself has been inspired by ODMG's OQL as JDOQL or JPAQL as well.

The guys at DB4O are also doing a good job and investigate new approaches. LinQ from Microsoft is alternate approach of statically checked queries.

Having an object-capable Query Language is a pre-requesite to manipulate Business Models.

This article, seen on InfoQ introduces the Objectivity Object Query Language.

JPA Spec Lead interview

Seen on InfoQ, this one hour interview of Linda DaMichael. Hopefully, JPA 2 will become much more complete in its scope and coverage of persistence needs. It is nice to see JPA is now standardized outisde the EJB 3 specification, because it is obviously a very generic standard. And eventually we'll be able to align and synchronize JPA and the DAS.

And JDO 2 is still here when persistence is not limited to RDBMS.

Xcalia is obviously committed to implement JPA2. Our JPA implementation will rely on our current JDO implementation.

JPA Spec Lead interview

Seen on InfoQ, this one hour interview of Linda DaMichael. Hopefully, JPA 2 will become much more complete in its scope and coverage of persistence needs. It is nice to see JPA is now standardized outisde the EJB 3 specification, because it is obviously a very generic standard. And eventually we'll be able to align and synchronize JPA and the DAS.

And JDO 2 is still here when persistence is not limited to RDBMS.

Xcalia is obviously committed to implement JPA2. Our JPA implementation will rely on our current JDO implementation.

Wednesday, January 9, 2008

SDO identity

I've heard several complaints about the lack of identity in SDO. This is sadly true and even more critical for the DAS.

The SDO / DAS expert groups are working on it. We should have a solution for that in upcoming versions of these standards.

SDO identity

I've heard several complaints about the lack of identity in SDO. This is sadly true and even more critical for the DAS.

The SDO / DAS expert groups are working on it. We should have a solution for that in upcoming versions of these standards.

Fluid: a JPA-based DAS experiment

Pinaki Poddar started an initiative within Apache Labs for a JPA-based DAS (Fluid).

He explored a JPA-based DAS approach via Fluid which is an Apache Lab project signifying its exploratory approach.

Fluid, through a prototype implementation, establishes the feasibility of such an approach without any modification to JPA.

More information on Fluid can be found at:

Fluid: a JPA-based DAS experiment

Pinaki Poddar started an initiative within Apache Labs for a JPA-based DAS (Fluid).

He explored a JPA-based DAS approach via Fluid which is an Apache Lab project signifying its exploratory approach.

Fluid, through a prototype implementation, establishes the feasibility of such an approach without any modification to JPA.

More information on Fluid can be found at:

SDO a new standard for persistence?

Definitely not!

There is some confusion about SDO in the industry. I've recently seen posts and comments in various blogs and expert groups spreading misconceptions about SDO.

It seems they are afraid by SDO or DAS trying to define yet another standard for persistence.

Here is my answer to them:

AFAIK, I think the SDO group is not trying to redefine a new persistence standard... as SDO is not really related to persistence by itself.

IMHO, you should rather look at SDO as a standard for DTO. The DAS itself is in charge of accessing and manipulating the data sources. The DAS expert group is certainly not willing to specify a new way to manipulate data sources. The DAS specification is rather focusing on defining the protocol between the various DAS components and their interaction with SDO. So existing standards like JPA and JDO are obviously best candidates for Java-ORM-oriented DAS implementations. But keep in mind the DAS specification is neither limited to Java nor to RDBMS. And even in the case of a single RDBMS, mapping (ORM) is not mandatory.

I think that is more or less what Tuscany is illustrating today (JDBC-based DAS).

BTW: Tuscany is just an example of what a DAS could be. I'm aware of at least 2 other DAS implementations built upon JPA and another one relying on top of JDO. I think there is nothing in JPA today preventing implementation of a DAS on top of it. The same way, I cannot see missing features in JPA today for a DAS implementation.

See also Michael Rowley's (BEA) point of view.

SDO a new standard for persistence?

Definitely not!

There is some confusion about SDO in the industry. I've recently seen posts and comments in various blogs and expert groups spreading misconceptions about SDO.

It seems they are afraid by SDO or DAS trying to define yet another standard for persistence.

Here is my answer to them:

AFAIK, I think the SDO group is not trying to redefine a new persistence standard... as SDO is not really related to persistence by itself.

IMHO, you should rather look at SDO as a standard for DTO. The DAS itself is in charge of accessing and manipulating the data sources. The DAS expert group is certainly not willing to specify a new way to manipulate data sources. The DAS specification is rather focusing on defining the protocol between the various DAS components and their interaction with SDO. So existing standards like JPA and JDO are obviously best candidates for Java-ORM-oriented DAS implementations. But keep in mind the DAS specification is neither limited to Java nor to RDBMS. And even in the case of a single RDBMS, mapping (ORM) is not mandatory.

I think that is more or less what Tuscany is illustrating today (JDBC-based DAS).

BTW: Tuscany is just an example of what a DAS could be. I'm aware of at least 2 other DAS implementations built upon JPA and another one relying on top of JDO. I think there is nothing in JPA today preventing implementation of a DAS on top of it. The same way, I cannot see missing features in JPA today for a DAS implementation.

See also Michael Rowley's (BEA) point of view.

Tuesday, January 8, 2008

Distributed JPA

http://www.theserverside.com/news/thread.tss?thread_id=48000

http://people.apache.org/~ppoddar/slice/site/

There is definitely a need for that.

Reminds me of C-JDBC (clustered JDBC):

Requirements for distribution of databases are somewhat close to those of Data Access in SOA.

Distributed JPA

http://www.theserverside.com/news/thread.tss?thread_id=48000

http://people.apache.org/~ppoddar/slice/site/

There is definitely a need for that.

Reminds me of C-JDBC (clustered JDBC):

Requirements for distribution of databases are somewhat close to those of Data Access in SOA.

SDO & DAS Face-2-Face meetings

This week we have the first DAS 1 et SDO 3 face-to-face meetings. I hope we'll be able to reach significant milestones for these very important standards for Data Access in SOA. These meetings are kindly hosted by SAP in Berlin.

I remember the JDO face to face meetings had been very efficient in the past, we have been able to achieve in few hours much more than during the previous months.

We had no face-to-face meetings for SDO 1 and 2 yet, and I think it was missing.

The same way we never had any face to face meetings for JPA :-(

SDO & DAS Face-2-Face meetings

This week we have the first DAS 1 et SDO 3 face-to-face meetings. I hope we'll be able to reach significant milestones for these very important standards for Data Access in SOA. These meetings are kindly hosted by SAP in Berlin.

I remember the JDO face to face meetings had been very efficient in the past, we have been able to achieve in few hours much more than during the previous months.

We had no face-to-face meetings for SDO 1 and 2 yet, and I think it was missing.

The same way we never had any face to face meetings for JPA :-(

Friday, January 4, 2008

Thursday, January 3, 2008

IBM PureQuery

Project formely known as JLINQ.

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0708ahadian/

http://www-306.ibm.com/software/data/studio/purequery/ (IBM Data Studio)

http://en.wikipedia.org/wiki/IBM_PureQuery

http://db2mag.com/story/showArticle.jhtml?articleID=202400140

It seems it used within Project Zero:

http://www.projectzero.org/wiki/bin/view/Documentation/DataAccess

It is unfortunately limited to Java and RDBMS.

Here is an example:

Data data = DataFactory.getData (datasource);
// Insert an employee of type Employee bean in the database
data.update("insert into EMPLOYEE (EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT, PHONENO, HIREDATE, JOB, EDLEVEL, SEX, BIRTHDATE, SALARY,
BONUS, COMM) values( :employeeNumber, :firstName, :midinit, :lastname, :workdept, :phoneno, :hiredate, :job, :edlevel, :sex,
:birthdate, :salary, :bonus, :commision)"
, employee);

// Query the database for employees
Iterator<Employee> employee = data.queryIterator ("select * from EMPLOYEE where EMPNO = :employeeNumber", Employee.class);

I like the idea behind ProjectZero, but is JLINQ really what you expect from a modern Data Access layer?

IBM PureQuery

Project formely known as JLINQ.

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0708ahadian/

http://www-306.ibm.com/software/data/studio/purequery/ (IBM Data Studio)

http://en.wikipedia.org/wiki/IBM_PureQuery

http://db2mag.com/story/showArticle.jhtml?articleID=202400140

It seems it used within Project Zero:

http://www.projectzero.org/wiki/bin/view/Documentation/DataAccess

It is unfortunately limited to Java and RDBMS.

Here is an example:

Data data = DataFactory.getData (datasource);
// Insert an employee of type Employee bean in the database
data.update("insert into EMPLOYEE (EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT, PHONENO, HIREDATE, JOB, EDLEVEL, SEX, BIRTHDATE, SALARY,
BONUS, COMM) values( :employeeNumber, :firstName, :midinit, :lastname, :workdept, :phoneno, :hiredate, :job, :edlevel, :sex,
:birthdate, :salary, :bonus, :commision)"
, employee);

// Query the database for employees
Iterator<Employee> employee = data.queryIterator ("select * from EMPLOYEE where EMPNO = :employeeNumber", Employee.class);

I like the idea behind ProjectZero, but is JLINQ really what you expect from a modern Data Access layer?

MS ADO .Net Data Service

Microsoft is clearly going in the right direction with the project formerly known as Astoria, now officially ADO .Net Data Services and with the Entity Framework.

http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx

http://blogs.msdn.com/astoriateam/default.aspx (the Astoria project team blog)

Even if they never liked it in the past (see the ObjectSpaces story) they will follow the path to mapping technologies, because that's the best way to implement MDA.

The problem is to guess when these technologies will be:

  1. Really usable (today it is just a beta).

  2. All components will be really integrated, end-to-end: LinQ -> Entities -> ADO .Net.

  3. Usable outside the Microsoft environment, at least for the supported data sources, e.g. not limited to SQL Server.

  4. At the end, it will ne nice to understand when a consistent and comprehensive solutions will be available. During some quarters (years?), Microsoft customers will still have to mix various technologies and will have to decide which of the several approaches available will perform the best for them.


In the meantime .Net programmers can already try Xcalia SDO / DAS for .Net. They will be able to use LinQ to query against its logical business model and perform an efficient mapping with all the data sources XIC supports: RDBMS, XML, Web Services, mainframe transactions, packaged applications, components, etc.

MS ADO .Net Data Service

Microsoft is clearly going in the right direction with the project formerly known as Astoria, now officially ADO .Net Data Services and with the Entity Framework.

http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx

http://blogs.msdn.com/astoriateam/default.aspx (the Astoria project team blog)

Even if they never liked it in the past (see the ObjectSpaces story) they will follow the path to mapping technologies, because that's the best way to implement MDA.

The problem is to guess when these technologies will be:

  1. Really usable (today it is just a beta).

  2. All components will be really integrated, end-to-end: LinQ -> Entities -> ADO .Net.

  3. Usable outside the Microsoft environment, at least for the supported data sources, e.g. not limited to SQL Server.

  4. At the end, it will ne nice to understand when a consistent and comprehensive solutions will be available. During some quarters (years?), Microsoft customers will still have to mix various technologies and will have to decide which of the several approaches available will perform the best for them.


In the meantime .Net programmers can already try Xcalia SDO / DAS for .Net. They will be able to use LinQ to query against its logical business model and perform an efficient mapping with all the data sources XIC supports: RDBMS, XML, Web Services, mainframe transactions, packaged applications, components, etc.

Data Services Ecology (2)

IMHO Data Services are key to MDA, because they ley developers focus on their business model.

This remark leads me to 2 important related technologies for Data Services:

  • Automatic User Interface

    • See what NakedObjects (www.nakedobjects.org) is doing, and how they progressively integrate Data Access frameworks (OK, I agree: essentially Hibernate until now).

    • See the XML UI description approach and mostly XAML


    • Navilis is a component we had in XIC since the beginning, and there are both Swing and JSP versions of it:

      • It creates an automatic UI from the persistent business model.

      • You can CRUD the model.

      • You can even run business methods and perform relatively complex queries.





  • Dynamic Languages

    • Groovy and JRuby will be become even more important in 2008

    • See how Groovy now has, GORM an integration with a Data Access layer (OK, I agree again: still limited to Hibernate).

      • Unfortunately this one is tightly coupled with Grails. I have no problem with Grails by itself, but I would certainly prefer to have GORM usable outside Grails and I would also prefer to have it relying on a standard like JPA2 or JDO2.



    • Integration of Groovy with Data Services seems key to me

      • I really would like to setup a prototype of a SDO/DAS Groovy interface in 2008.





Data Services Ecology (2)

IMHO Data Services are key to MDA, because they ley developers focus on their business model.

This remark leads me to 2 important related technologies for Data Services:

  • Automatic User Interface

    • See what NakedObjects (www.nakedobjects.org) is doing, and how they progressively integrate Data Access frameworks (OK, I agree: essentially Hibernate until now).

    • See the XML UI description approach and mostly XAML


    • Navilis is a component we had in XIC since the beginning, and there are both Swing and JSP versions of it:

      • It creates an automatic UI from the persistent business model.

      • You can CRUD the model.

      • You can even run business methods and perform relatively complex queries.





  • Dynamic Languages

    • Groovy and JRuby will be become even more important in 2008

    • See how Groovy now has, GORM an integration with a Data Access layer (OK, I agree again: still limited to Hibernate).

      • Unfortunately this one is tightly coupled with Grails. I have no problem with Grails by itself, but I would certainly prefer to have GORM usable outside Grails and I would also prefer to have it relying on a standard like JPA2 or JDO2.



    • Integration of Groovy with Data Services seems key to me

      • I really would like to setup a prototype of a SDO/DAS Groovy interface in 2008.





Wednesday, January 2, 2008

Data Services ecology

Data Services in SOA directly relates to several existing technologies and extends them:

  • Persistence, known as ORM in the past.

  • Integration, connectors to access packaged applications and/or exotic legacy data sources.

  • Web Services.


In the middle, between persistence and services you will find SDO, where in the past you knew JDO or JPA.

Between Integration and services, EAI is evolving into ESBs. It is more standardized and relies on XML and Web Services but at the end it is still asynchronous messaging.

To some extent, Data Services are an extension of mapping to services in a disconnected model.

There are some other related technologies:

  • Security,

  • Management,

  • Cache,

  • ...

Data Services ecology

Data Services in SOA directly relates to several existing technologies and extends them:

  • Persistence, known as ORM in the past.

  • Integration, connectors to access packaged applications and/or exotic legacy data sources.

  • Web Services.


In the middle, between persistence and services you will find SDO, where in the past you knew JDO or JPA.

Between Integration and services, EAI is evolving into ESBs. It is more standardized and relies on XML and Web Services but at the end it is still asynchronous messaging.

To some extent, Data Services are an extension of mapping to services in a disconnected model.

There are some other related technologies:

  • Security,

  • Management,

  • Cache,

  • ...

Data Services duality

Data Services have a dual personality in SOA:

  • They can be data providers

    • In that sense they have some specific characteristics, for instance they are mostly transactional and synchronous.



  • They can be interfaces, for instance a Data Service will publish some data and will allow updates


A DAS for instance is able to aggregate and manipulate data through a Data Service it exposes but at the same time, the same DAS can consume other Data Services and integrate their data.

This is exactly what the Xcalia DAS is doing. It consumes and provides Data Services.

Data Services duality

Data Services have a dual personality in SOA:

  • They can be data providers

    • In that sense they have some specific characteristics, for instance they are mostly transactional and synchronous.



  • They can be interfaces, for instance a Data Service will publish some data and will allow updates


A DAS for instance is able to aggregate and manipulate data through a Data Service it exposes but at the same time, the same DAS can consume other Data Services and integrate their data.

This is exactly what the Xcalia DAS is doing. It consumes and provides Data Services.

Incorporating Enterprise Data into SOA

On November 2006, InfoQ released an interesting article by Boris Lublinsky about Data Access in SOA.

http://www.infoq.com/articles/SOA-enterprise-data

Incorporating Enterprise Data into SOA

On November 2006, InfoQ released an interesting article by Boris Lublinsky about Data Access in SOA.

http://www.infoq.com/articles/SOA-enterprise-data