Business Events
Analysis
Integration Models
Frameworks
Bizevex

A comparison...

There are two dominant development frameworks for EAI, both of which Sierra supports: Microsoft's .NET initiative and Sun's Java 2 Enterprise Edition (J2EE). Each framework has strong advocates (and detractors) for many reasons, some  of them self-serving.  There are however entirely practical factors that recommend one paradigm over the other.  There is also a promise of common ground between them, in the form of Web services.

Microsoft .NET Framework

The Microsoft platform in its recent incarnation, collectively branded as “.NET,” provides a more structured framework for “business-centric” developers - those whose focus in on the end functionalities rather than the system resources. This is because MS tools and languages are themselves highly integrated, compelling a well-defined application objective from the outset. Moreover its IDE (integrated development environment), Visual Studio, is highly integrated with all underlying technologies. It also a mature well-known environment that enables developers to quickly create applications with minimal effort.

 The MS platform is most viable where a single platform dominates or where multiple programming languages are in use. Its advantages are best gained when development focuses on rapid development and a tight focus on application development and business needs rather than on building or customizing technically complex system services from much more granular components, as is the case with J2EE.

Another benefit of using .NET over J2EE is the support. Microsoft support is typically excellent and their MSDN website has extensive articles, code and toolkits to assist the novice .NET developer to become more efficient.

Sun J2EE Framework

Of the two frameworks, J2EE is made up far more granular building blocks. It's sometimes said that where Microsoft provides bricks, siding, and windows, the J2EE environment supplies lumber, nails, and sand.  Java programming is not bound to any specific functional objective or application model. This makes it the favored choice of developers who require highly flexible, self-service access to system resources and applications.

Unlike .NET, J2EE provides no integrated development environment in itself. There are many third-party Java-based IDEs, many well-built products with value-added features that help to increase productivity over straight J2EE development using a text editor and Java compiler. However, as the J2EE framework continues to grow, the task of mastering the ever-growing suite of technologies becomes even more daunting.

This becomes quite apparent when a problem or questions arise in a J2EE technology that is unfamiliar or new. It is true that here is much documentation available for J2EE on the Internet. And, if you are using a specific IDE, there is also support from that vendor as well. However, often the problems of integrating non-J2EE technologies with non-J2EE (databases, XML, etc. etc.) often pose some interesting issues that could be quite challenging to resolve, and for which as yet, there is little or no support to be found.

Renowned for its platform-independence, J2EE is not generally perceived to be strong in terms of performance. However, what it lacks in performance and ease of use it makes up for in ubiquity and scalability. It is has been adopted by nearly every commercially available OS platform. J2EE applications also afford much greater scalability than that available with .NET and Intel based hardware. J2EE best serves when it is the sole language for applications distributed over diverse platforms.

For more discussions comparing  .NET  and  J2EE, we recommend these these articles:

• Chad Vawter and Ed Roman comparison (The Server Side)
• Jim Farley comparison (Java O'Reilly)