A few months ago, CodeFutures sent out a survey in its monthly newsletter on SOA usage and performance problems. There were some surprising results.
The survey results can be summarized as:
-Three quarters of enterprises using Java are using or planning to use Service Oriented Archiectures
-Over 30% have scalability problems and 56% have performance problems due to bottlenecks
-The vast majority of Java developers surveyed believe they have high performance requirements
-About one third of the Java developers surveyed had groups using C++ as well and Web Services technology is still relevant for C++ development
Survey Data Quality
The survey sent out to about 7,000 Java developers – primarily in the US and Europe (Asian/South America/African developers were not surveyed, unless they were CodeFutures customers). There were about 500 responders, which is consistent with other items in CodeFutures' newsletters. An iPod nano was given as a prize. The survey profile is not typical of the overall market profile a few ways:
-FireStorm/DAO is commercial software, so it does not attract many developers looking for free, open source software, which is a substantial part of the overall Java market
-FireStorm/DAO, as a productivity tool, attracts a lot of consultants and system integrations – who would use a wider variety of technologies than in house development teams
-no attempt was made to make the survey anything more than a 'straw pole' of CodeFutures' developers. There was no demographic information collected on the responders. So developers from large and small companies, Europe and the US, were all given equal weight, and there's no way to give a breakdown.
Survey Results and Analysis
Q1: Are you currently using/planning to use Web Services/SOA technology in production?
Yes – 76.5%
Analysis: The results confirm that Web Services/SOA technology is now fully mainstream and has widespread acceptance, even if it is not yet in widespread use. Using standards-based specifications for SOA provides huge cost savings in the long run compared with proprietary middleware like MOM.
Q2: Do you have scalability problems with your Java applications?
Yes – 31%
Analysis: Technically not a surprise. But its interesting that almost 1 in 3 Java developers are willing to ADMIT scalability problems.
Q3: Do you have very high throughput requirements with your Java applications that are currently unmet?
Yes – 56.7%
Analysis: This is perhaps the most solid result in the survey because the question is very specific. The result seems very high, so this is perhaps the item that should be followed up in another survey.
Q4: Do you develop Java applications with very high performance requirements?
Yes – 84.5%
Analysis: What “very high performance” means is subjective, but what is important for architectural decisions is that Java developers BELIEVE the have high performance requirements. Note that the profile of the developers in this survey probably taints this result. One thing is sure, the traditional J2EE server farms approach to scalability is just not working (whereas the POJO movement is gaining traction).
Q5: Are there any development groups in your organization using C++?
Yes- 33.5%
Analysis: This seems very high, but that's probably because CodeFutures has very little exposure to the C++ market. The result may be higher than normal due to the profile of the CodeFutures newsletter subscription list, which favors the top end of the Java market – large enterprises – that were probably developing in C++ before Java was introduced.
Q6 - Is your organization currently maintaining applications in C++ that you may wish to use in Web Services/SOA architectures?
Yes: 30.1%
Analysis: This is an extraordinary percentage, but the question is “may wish” rather than a more definitive ‘plan to use’. Interestingly, there were many that responded No to having development groups using C++ but yes to being interested in C++ Web Services. That seems to imply that legacy applications written in C++ are going to be maintained and used through Web Services. Good news for vendors of C++ Web Services technology. CodeFutures was interested in this question because the SDO API is available in both C++ and Java.
Survey Agenda and Conclusions
The reason for the survey was to decide if it was a good strategy to develop FireStorm/SDO. CodeFutures needed to know if there was real demand for Service Data Objects, which is ideal for high-performance SOA applications in both Java and C++ (hence the questions).
As it happens, the Service Component Architecture specification was announced around the time of the survey, which of course, puts SDO in a completely different perspective and makes it a much more strategic decision.
PJ Murray
CodeFutures Software
Managers of developers using Java technology must deal with a specific range of domain-specific issues. Some of the Java technology issues that managers, rather than developers, must deal with are:
- Poor java developer productivity gains
- Changing Java developer profile
- Poor tools for mainstream Java developers
- Growing diversity of Java architectural and technological choices
- Increasing complexity of Java technology
- Heavyweight platforms
Poor Java Developer Productivity GainsImportant application development technology areas such as communications bandwidth, memory size, and processing power all grow exponentially. Software development has made some historical gains - binary to assembler, for example. However, most recent changes are incrementally better at best, and overall productivity is possibly getting worse due to added complexity.
Traditional Java software development techniques, which rely on “hand crafting” solutions, are no longer adequate to keep up with the demands placed on software development organizations. It is inevitable that hand coding repetitive and mundane tasks will be replaced by automatic code generation and that standardized application architectures will be used.
Changing Java Developer Profile
The typical skill level of Java developers and the type of organizations developing Java-based applications is predicted to change significantly. Almost all growth in developer numbers is expected to come from less skilled mainstream developers. This presents resource problems for project managers.
"Lack of qualified developers will be the No. 1 inhibitor of Java adoption among IS organizations. Consequently, mainstream IT enterprises will increasingly demand and depend on tools focused on minimizing the degree of expertise required to deliver "real world" solutions in competitive time frames. Increasingly, component-based solutions, business rules, code generators, model-driven toolsets, and emerging Web Services models, along with more comprehensive methodologies and integration strategies, are becoming critical for Java development markets.”
Source: New Rules and Realities for Java Technology Markets, Gartner Inc., October, 2002
Emerging Mainstream Java Developers Poorly Served by Java Tools Vendors
The response of Java tools to the changing developer profile has been very poor – especially when benchmarked against Microsoft. Most improvements have been incremental changes aimed at individual developer productivity –with very little done to increase productivity or improve teamwork.
“The profile of the average Java developer will change dramatically during the next five years. Moving from code-centric technology experts to mainstream rapid application development personnel. Java programmers will require tools and training that goes beyond today’s market-leading technologies.”
Source: The Face of the Java Developer is Changing, Gartner Inc., 2004
Code generators are perhaps the definitive tool to provide to less experienced or more mainstream developers. Not only does it save such developers from writing code, it also ensures that the code is error free.
Growing Diversity of Java Architectural and Technological Choices
The software industry has very solid foundations for delivering solid enterprise-grade applications, with operating systems such as UNIX/LINUX, relational databases, the Web, many XML specifications, and Java. A key problem is that software developers, and Java developers in particular, can not agree how to write applications. A large proportion of new development projects using Java technology start with almost a “clean sheet”, with development teams spending time and effort on technical analysis, new architectures, and new technologies, often while the project and development managers are left to worry about business requirements, deadlines, and budgets.
It is not unusual for software developers to be more interested in the technical challenges and opportunities of application development than business requirements. The Java ecosystem of competing products and technologies, while encouraging creativity and innovation, makes it even more difficult for project and development managers to focus the attention of technologists on business requirements.
“It is becoming clearer that today’s basic Java toolsets by themselves are not adequate. Java is too low level to be flexible and programmer productive; programmers must deal with too complex an architecture, with JSPs, J2EE, EJBs, very large class libraries, and so on, leading to unnecessary paralysis by analysis”
Source: Imperatives for a New Development Age: The Party’s Over, Aberdeen Group, February 2004
The problems associated with too much technological choice and architectural uncertainty are particularly true for Java persistence. Because up to 90% of enterprise applications use relational databases, the wide range of Java persistence architectures, technologies, and products can lead to projects loosing a lot of time through initial research.
Increasing Complexity of Java Technology
Java technology reached its tenth anniversary in 2005. It has evolved into the most comprehensive and sophisticated enterprise software development language. A major issue is that as the typical Java developer profile switches to more mainstream developers, Java technology is becoming more complex.
Number of Pages in J2EE Specification
J2EE 1.2 .............. 250
J2EE 1.3 .............. 550
J2EE 1.4 .............. 1,753
J2EE 1.5 .............. lost count!
The core Java technology, the J2EE specification, has increased in complexity to point where it is no longer productive for all developers in a development team to have knowledge of the entire specification. It is even difficult now for senior Java architects to have detailed knowledge of the entire J2EE specification.
Heavyweight, Over-Engineered Platforms
This is primary the fault of Java product vendors and their sales models. To support prices of $10,000 or $20,000 per CPU, a 'platform' is required. How many vendors talk about thier products been lightweight, easy to deploy, and easy to manage? The traditional approach to scalability for these 'platforms' is server farms, which means lots more CPUs and more product revenue. The fact that there's a reducing return on investment with server farms because they do not scale linearly is great news to the 'platform' vendors - that means more CPU sales. So there's no real incentive to make products scalable and high performance.
Some Simple Tips for Success
CodeFutures advises many project managers and technical architects on the various Java persistence technologies available (JDBC, JDO, EJB CMP, Hibernate, SDO). Because FireStorm/DAO supports all the main Java persistence technologies, CodeFutures has nothing to gain from recommending one particular Java persistence technology. Some advise CodeFutures gives to its customers:
- do not rely on any one vendor for anything
- always avoid proprietary products, insist on support for industry specifications
- there are rarely one-size-fits-all enterprise wide solutions
- you need a very, very good reason to use J2EE, otherwise keep application architectures as simple as possible
- after much hype, SOA has finally arrived
- ask vendors for Return-on-Investment calculations
- avoid 'platforms' and always ask for linear scalability
PJ Murray
CodeFutures Software
A fundamental part of the value proposition of Services-Oriented Architectures is interoperability. An entire EAI market exists because historically everything was proprietary.
A Break From the Past
HIstorically, the software industry could never agree on standards. In fact, EAI and MOM vendors were probably fine with the situation because it provided customer lock-in. The DCOM versus CORBA battles of the 1990s showed the importance of having common infrastructure standards. The emergence of XML and then SOAP was a direct result of the DCOM/CORBA war. Even Microsoft has learned the lesson and now participates in the development of the Web Services standards to provide interoperabilty with the rest of its otherwise proprietary product lines.
Everything works together
Once you have standards, you can connect anything to anything.The entire software industry has agreed on the Web Services stack as being the common glue that can be used to stick everything together. It's as simple as that.
So if your SOA is not standards-based, it's missing the point of the exercise.
PJ Murray
CodeFutures Software
