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...
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 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....[WebAttack.com latest software][via Sam Gentile's Blog]
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... ;)
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!
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 http://www.ingorammer.com/contact/Newsletter.aspx.Subscribed!
I'm probably the last one to find out about Kartoo, but it's really cool.
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.