http://searchwebservices.techtarget.com ... 11,00.html
Moved by alexo
JAVA EE στα τελευταια της;
-
nocturna_gr
- byte level
- Posts: 122
- Joined: Tue Sep 27, 2005 2:20 pm
"Death knell for J5EE sounded too early"
http://www.theinquirer.net/default.aspx?article=33103
AS REPORTED BY The INQ last week, senior analyst Richard Monson-Haefel of the Burton group has stated that the increasing complexity of JEE will bring forward its own demise to within the next five years. Some of us don't see it as so clear cut.
There are a few frameworks with the necessary inherent complexity to build robust, secure, multi-platform, scalable solutions, like JEE delivers today. It could be argued that the only modern equivalent is the rival Microsoft-based .NET architecture when in its full web-service orientated guise. There are more complex solutions that can be developed using a mix of, say, C++, CORBA etc, but the complexity of these proprietary models is vast, often assuming a working knowledge of many different languages and non-inter-related components, with pre-existing systems being seen as development nightmares for new developers being added to the mix. Suffice to say, JEE and .NET are widely regarded as the main (and only) solutions for green-field enterprise projects being built today.
Choose .NET and you're inherently tied in to Microsoft product, whichever way you look. MS SQL Server is pushed as the database of choice, Visual Studio is the 'must-have' IDE solution for .NET. Yes there are other non-MS choices in these areas, but the .NET run-time (CLR) is prohibitively made available by Microsoft for Windows servers only. Microsoft can argue TCO for Windows as much as they like, but the majority of developers do not wish to be tied to MS in any way. And yes, there are open-source initiatives to bring .NET to Linux et al, but they will always be feature-incomplete and considerably lagging compared to MS's own deliveries. Sun's offering of 'specifications' to its language and solutions are developed and adhered to by open-source groups and commercial organisations alike, allowing full escape from any vendor tie-in.
Its too complex
Many arguments are currently being made for Ruby-On-Rails or similar 'simple to develop' technologies. These arguments are inherently flawed. Ruby, and the like, cannot offer the built-in support of complexity that enterprise architectures allow. Its agreed that these quick-to-market solutions offer massive gains in ease-of-development and resulting costs, but they cannot offer out-of-the-box secure, multi-tier, scalable solutions with support for advanced concepts such as RMI. Massive development and complexity would need to be added, similar to that offered by JEE, diminishing any advantage these light-weight frameworks offer. They simply are not comparable to the offerings of multi-tier enterprise architectures we already have in the form of JEE/.NET.
Now to SOA
SOA is the big buzz-term at the moment. As its name suggests, Service Orientated Architecture focuses on how services relate and communicate with one-another. The Burton group discussed how Sun has over-complicated JEE to ensure SOA-like capabilities and how JEE is inherently unable to be utilised efficiently for SOA-type development. This is pure nonsense. It's impossible to think of a current platform that isn't more readably utilisable for SOA than enterprise Java.
SOA isn't a language or an exacting-specification, it's a general design principle. SOA has always been available for implementation via J2EE's inherent web-facing infrastructure including Servlets, Message Beans, and the useful coupling of Apache Axis, which allows full web-service generation from existing Java classes. J5EE delivers further Sun-specified support of web-services with a substantial amount of additional APIs for SOA-like development use.
This talk of Java's concept of one 'object instance pre service' not being relevant to SOA is rubbish. Multiple instances allow multiple services, all slightly differently configured for various end-consumers, all from very little change, and from one underlying object specification. Anyway, this argument goes against the grain of what SOA is all about – the underlying architecture and language of choice is irrelevant (and OO design is unlikely to die anytime soon), it's the service and standardised communication that is most important.
Monson-Haefel also criticises the portability of Java across multiple system architectures and operating systems stating that "interoperability is much more important" – surely the fact the system is truly portable allows further abstraction into the SOA ideology, you do not have to worry about underlying system's architectures, only about your interoperable services. Java portability is certainly not as difficult to introduce into development as the report suggests, very minimal changes are ever needed for a web-service based infrastructure that SOA development requires.
Conclusion
The Burton report doesn't really stand its ground under some brief analysis, and it seems they've combined the latest hip design paradigm word with the typical anti-Java/pro-Ruby vibe to ensure a widely published paper.
It's safe to assume that many current development teams will choose JEE as their model of choice, people do not wish to be tied in to Microsoft and .NET, which has generally lagged Sun's offerings and blatantly 'borrowed' many of its existing solutions, nor do they wish to utilise architectures that cannot instantly offer what they require. Masses of existing online banks, financial institutions, online casinos and a plethora of other internet-based services currently use Enterprise Java solutions. These companies that are heavily reliant on existing services will not wish to move away, and completely redevelop using new architectures any time soon. Enterprise Java is here to stay, and for some time to come
http://www.theinquirer.net/default.aspx?article=33103
AS REPORTED BY The INQ last week, senior analyst Richard Monson-Haefel of the Burton group has stated that the increasing complexity of JEE will bring forward its own demise to within the next five years. Some of us don't see it as so clear cut.
There are a few frameworks with the necessary inherent complexity to build robust, secure, multi-platform, scalable solutions, like JEE delivers today. It could be argued that the only modern equivalent is the rival Microsoft-based .NET architecture when in its full web-service orientated guise. There are more complex solutions that can be developed using a mix of, say, C++, CORBA etc, but the complexity of these proprietary models is vast, often assuming a working knowledge of many different languages and non-inter-related components, with pre-existing systems being seen as development nightmares for new developers being added to the mix. Suffice to say, JEE and .NET are widely regarded as the main (and only) solutions for green-field enterprise projects being built today.
Choose .NET and you're inherently tied in to Microsoft product, whichever way you look. MS SQL Server is pushed as the database of choice, Visual Studio is the 'must-have' IDE solution for .NET. Yes there are other non-MS choices in these areas, but the .NET run-time (CLR) is prohibitively made available by Microsoft for Windows servers only. Microsoft can argue TCO for Windows as much as they like, but the majority of developers do not wish to be tied to MS in any way. And yes, there are open-source initiatives to bring .NET to Linux et al, but they will always be feature-incomplete and considerably lagging compared to MS's own deliveries. Sun's offering of 'specifications' to its language and solutions are developed and adhered to by open-source groups and commercial organisations alike, allowing full escape from any vendor tie-in.
Its too complex
Many arguments are currently being made for Ruby-On-Rails or similar 'simple to develop' technologies. These arguments are inherently flawed. Ruby, and the like, cannot offer the built-in support of complexity that enterprise architectures allow. Its agreed that these quick-to-market solutions offer massive gains in ease-of-development and resulting costs, but they cannot offer out-of-the-box secure, multi-tier, scalable solutions with support for advanced concepts such as RMI. Massive development and complexity would need to be added, similar to that offered by JEE, diminishing any advantage these light-weight frameworks offer. They simply are not comparable to the offerings of multi-tier enterprise architectures we already have in the form of JEE/.NET.
Now to SOA
SOA is the big buzz-term at the moment. As its name suggests, Service Orientated Architecture focuses on how services relate and communicate with one-another. The Burton group discussed how Sun has over-complicated JEE to ensure SOA-like capabilities and how JEE is inherently unable to be utilised efficiently for SOA-type development. This is pure nonsense. It's impossible to think of a current platform that isn't more readably utilisable for SOA than enterprise Java.
SOA isn't a language or an exacting-specification, it's a general design principle. SOA has always been available for implementation via J2EE's inherent web-facing infrastructure including Servlets, Message Beans, and the useful coupling of Apache Axis, which allows full web-service generation from existing Java classes. J5EE delivers further Sun-specified support of web-services with a substantial amount of additional APIs for SOA-like development use.
This talk of Java's concept of one 'object instance pre service' not being relevant to SOA is rubbish. Multiple instances allow multiple services, all slightly differently configured for various end-consumers, all from very little change, and from one underlying object specification. Anyway, this argument goes against the grain of what SOA is all about – the underlying architecture and language of choice is irrelevant (and OO design is unlikely to die anytime soon), it's the service and standardised communication that is most important.
Monson-Haefel also criticises the portability of Java across multiple system architectures and operating systems stating that "interoperability is much more important" – surely the fact the system is truly portable allows further abstraction into the SOA ideology, you do not have to worry about underlying system's architectures, only about your interoperable services. Java portability is certainly not as difficult to introduce into development as the report suggests, very minimal changes are ever needed for a web-service based infrastructure that SOA development requires.
Conclusion
The Burton report doesn't really stand its ground under some brief analysis, and it seems they've combined the latest hip design paradigm word with the typical anti-Java/pro-Ruby vibe to ensure a widely published paper.
It's safe to assume that many current development teams will choose JEE as their model of choice, people do not wish to be tied in to Microsoft and .NET, which has generally lagged Sun's offerings and blatantly 'borrowed' many of its existing solutions, nor do they wish to utilise architectures that cannot instantly offer what they require. Masses of existing online banks, financial institutions, online casinos and a plethora of other internet-based services currently use Enterprise Java solutions. These companies that are heavily reliant on existing services will not wish to move away, and completely redevelop using new architectures any time soon. Enterprise Java is here to stay, and for some time to come
