Communities
|
Social Applications
Networks
Knowledge Base
Support
|
|
C-Level Executives
Other Roles
|
|
Support
Education
Partner
Other Tasks
|

Oracle Labs
|
||||||||||||
|
|
|
June 4, 2002 -- If traditional software development tools keep getting better, why does software development keep getting harder? The fact is, enterprise application development today is still characterized by frustration. Programmers feel it as they struggle to create dynamic applications using manual coding tools. IT managers feel it when senior executives suddenly change the core requirements of a software project that has been in the works for months. And executives feel it when they see the company miss a key business opportunity because the IT department couldn't build the needed software in the required time frame. Object-oriented development and code reuse techniques were supposed to increase the productivity of developers. But today, programmers still face huge and growing backlogs of development projects. Clearly, it's time for a better option. It's time for a technology that can cut development cycles, simplify transitions from one architecture to another, and improve application performance and scalability--all at the same time. Take a Look at Ace.Project Ace is one of the most promising advances in software development in years. Created by a research team at Sun Microsystems Laboratories, Ace technology enables developers to simplify and automate the development of enterprise Java applications, create applications that are easy to migrate from one architecture to another, and optimize performance and scalability. Here's how it delivers on the promise. Simpler, Faster Development Process The key breakthrough Ace brings to the development community is the ability to transform business requirements or specifications into automatically generated, correctly coded, smooth-running applications. Ace is unique because it provides a natural way for developers to describe the "intent" of the application precisely, as opposed to manually writing the code that implements that intent. In other words, developers use Ace to create a high-level specification that provides enough information so that Ace can automatically generate the implementation code for the application. It completely separates the implementation details of a distributed application from its specification. And this has huge implications for both developers and business executives:
Architecture Choices Kept Open Today's Web-centric computing has resulted in new architectural models and new technology choices that companies want to take advantage of. For example, 2-tier models (client-Web server-database) may be best for small, lightly used applications, but companies might want to deploy a 3-tier architecture (client-Web server-application server-database) for complex, high-traffic applications and Web services. Ace has been very carefully designed to be architecture-independent. That means developers can use Ace to regenerate the application's code for new architecture and technology choices, just like a conventional compiler can generate code for different processors. For example, a developer could create an application initially for use in a 2-tier architecture and, as the volume of usage increases, simply regenerate it later for use in the more powerful 3-tier. This architectural agility gives businesses the ability to "Write Once, Deploy Anywhere." This has multiple benefits:
Optimize Performance, Improve Scalability of Applications The code that Ace generates is automatically performance-optimized for a given architecture and technology choice. By dramatically improving application performance, Ace can also increase application scalability. Equally important, Ace can improve the performance and scalability of existing applications as well as new applications. Thus, programmers can reverse-engineer existing applications into Ace, making it easy to adopt different architectures. |
The second half of an Ace specification is a description of how the application will manipulate that data, that is, its business process tasks. These business process tasks and their sequencing are represented visually in another diagram. For example, here is the business process diagram for the PurchaseOrder application: A business process task diagram is then further enhanced with information about its object access, user interactions, invocations of business logic, and transactions. | |||
