Subscribe: Andres Aguiar's Weblog
Added By: Feedage Forager Feedage Grade B rated
Language: English
applications  code  deklarit  free monitor  free  google  jca  microsoft  monitor google  net  newsletter  soap apis  via  web  weblog  yukon 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Andres Aguiar's Weblog

Andres Aguiar's Weblog

Right here, right now

Last Build Date: Wed, 26 Mar 2003 02:32:32 GMT

Copyright: Copyright 2003 Andres Aguiar


Wed, 26 Mar 2003 02:29:36 GMT


My notebook motherboad died, and I was 3 weeks without being able to recover the hard drive, which had the weblog content.

I decided to use a blogging software that lets me post from any machine, and I moved to The RSS feed is in

Please update your links and feeds.

See you there...

Amazon .NET books delivered via RSS

Mon, 24 Feb 2003 14:31:40 GMT

Amazon .NET books delivered via RSS: A chap called Sean Nolan has been messing with the Amazon web services and has created an RSS feed that returns a list of books that match a search term. [Cool.]

Microsoft and the corporate market

Fri, 21 Feb 2003 03:36:33 GMT

There are three 'platforms' for building corporate applications today: J2EE, Microsoft.NET and the 'Open Source' platform. In the later I also include Java software that is not J2EE like Struts, WebWork, Hibernate, Castor, etc, etc.

Comparing the three, J2EE is the one that moves slower. .NET moves fast, as Microsoft decides what happens with it without having to discuss with anyone, and the open source community is probably the one that moves faster, even if with no clear direction.

In the last week I had couple of meetings with people from a big oil company and an airline company. Both have J2EE as their standard platform.

Slow moving is not a problem for most corporations. They usually move slowly, and they feel comfortable with 'designed by committee' technologies, so J2EE has a good value proposition for them.

Microsoft has not a good record on providing a stable platform for developers. I really believe this changed with .NET, but is not easy to convince a company that has tons of VB6 and ASP code that MS won't change it again.

Corporations have also other big fear, which is being a prisoner of a vendor. You can argue that J2EE is not portable, but you can also believe it is, and it's better to have a hope than to have no hope.

If you choose .NET you are deciding to buy Microsoft software from now on. You want to pay for it and you are happy with that. What you do not want is MS to overcharge you, and if you have reasons to think MS will do that if they have the chance, then it's hard to take that option.

I am not sure how bad it really was, but last year's changes in MS licensing terms was perceived as an abuse of MS power, and it could help MS to lose the real battle...


WebServices or J2EE Connector Architecture

Wed, 19 Feb 2003 21:07:03 GMT

I'll have a meeting with a guy who will defend using JCA for application integration. I'm not a JCA expert, but as far as I know JCA is trying to solve the same problem as WebServices.

The only article I found discussing about this was in a BEA site, and I do not agree with the author. He says that you cannot compare the two, and the main reason it gives is that Websevices are more 'intrusive' as you need to build a stack for the legacy server, and with JCA you just use the existing APIs. If that's the main reason, I think they _are_ competing with each other.

Sun built/is building a whole EAI stack for JCA, and it is also building it for WebServices... is there a reason for this?

Of course I think webservices is a better solution, even if it is more complex, as it's a cross-platform and cross-language solution.

Can anyone help me to clarify this? Will JCA have a future?

On the other side, the BEA article made me think that Microsoft really needs the Enterprise Applications vendors to build SOAP APIs for their products. Perhaps this Microsoft entry into the Enterprise Application market (Great Plains, Navision) is, among other reasons, to force their competition to build the SOAP APIs. If MS products have good SOAP APIs, as they will, the other vendors would have to build them to compete with MS.

Free! - Free Monitor for Google 1.2 beta 1

Thu, 13 Feb 2003 05:42:45 GMT

Free! - Free Monitor for Google 1.2 beta 1 Free Monitor for Google is an easy to use web site promotion aid for webmasters. It allows you to find and track your position in the Google search engine results for specified keywords. You can keep....[ latest software]

This weblog ranks #1 for Andres Aguiar, and that is not suprising, but ranking #7 for Andres it is, as this isn't really a high-traffic weblog. I guess having a non-English name improves your chances of having a well google-ranked weblog... ;)



DeKlarit 2.0

Thu, 13 Feb 2003 05:33:27 GMT

While I'm in Bellevue attending to a ND Microsoft event, our team released DeKlarit 2.0.

We put a lot of work in this release, and we are proud of it, but of course we are dreaming with the features 3.0 will have.

The main features 2.0 are support for Oracle, VB.NET code generation and VS.NET 2003 integration. As the code generator is written in Prolog, the VB.NET thing was not just using another serializer for a CodeDom ;), but as it is written in Prolog, it was quite easy to do too.

Some interesting things happened in the way from 1.x to 2.x. One was the requirement to generate VB.NET. When we started the DeKlarit project, about 2 years ago, we thought that the language wars will be over with .NET, but some people still wanted VB.NET code instead of C# code, even if they were not going to modify the code DeKlarit generates. We were wrong, and after some "call me when it supports VB.NET's we decided to go for it.

DeKlarit is a tool that generates the Data Access Layer and Business Logic Layers of an application, but it takes as input 'user-views' of the business entities, it generates DataSets with those user views, and it adds additional metadata to the DataSets. Using that metadata, in version 1.0 we built some add-ins that read it and generated ASP.NET apps, Windows Forms apps, and a Web Service layer.

So, the other requirement was to improve those add-ins.  I'm really not a user-interface guy, and I think our main competitive advantage is not there, but we ended up doing it, so we have a much better ASP.NET generator.

The ASP.NET generator saves a lot of work, but the UI-paradigm it follows is not revolutionary, it's a pretty common approach to web applications. 

I'm looking for different/revolutionary ways to design a UI for database-centric web applications, not for an Amazon-like e-commerce site but for ERP-like applications. If you have any ideas, links, etc, they will be welcome!


Distributed .NET Newsletter

Thu, 13 Feb 2003 01:13:46 GMT

Early next week, I'll send out the first issue of my free Distributed .NET Newsletter.

This bi-weekly newsletter contains real world tips and tricks about .NET Remoting, Web Services and EnterpriseServices, and design guidance for distributed applications. You'll also find the occasional pointers to other free resources like white papers, patterns&practices documents or other great samples on the web.

You can subscribe to the newsletter in HTML or plaintext format at



Wed, 05 Feb 2003 05:52:20 GMT

I'm probably the last one to find out about Kartoo, but it's really cool.

Yukon and CLR Types

Wed, 05 Feb 2003 05:51:13 GMT

People seemed to like the idea that you can store CLR types inside Yukon.

I like the idea too, but don't get confused.. this is not turning Yukon into an OO-Database and it's not giving Yukon a way to automatically persist your domain objects (i.e., your Customer or your Order). It will work for complex types that have no meaning when split into its simple components, like the 'Point' type.

Unless they do things like letting you create indexes by these object's fields, and create integrity relations between them, etc, the way to work with data will still be the old-and-great relational model.

The Yukon implementation seems to follow Chris Date's Third Manifesto, where he says that in the relational model objects map to domains, not to relations, as we usually do when building our data access layers.