HandBooks Professional Java-C-Scrip-SQL part 16 ppsx

Enterprise Integration In some ways, C redefined enterprise integration, by allowing strong database connectivity across an open API ODBC for Microsoft applications and providing transac

5.2 Enterprise Integration

In some ways, C redefined enterprise integration, by allowing strong database connectivity across an open API (ODBC for Microsoft applications) and providing transaction monitors like Tuxedo and Encina C was disruptiveit introduced

enterprise programming beyond mainframes Java continued this legacy with

frameworks for transactions, rich database integration, messaging, and many other forms of plumbing code called middleware

I don't think the next major applications language will initially have to have the full enterprise capabilities of C or Java to succeed Visual Basic certainly achieved tremendous success without these capabilities by leveraging the services provided

by other frameworks written in lower-level languages like C We've already

determined that the next language should interoperate with other Java programs, hopefully within the same virtual machine It should also interoperate through a coarse-grained service layer That said, some enterprise capabilities will be very important

5.2.1 Database Integration

Minimally, a new language should access relational databases in a natural,

productive way I don't think any particular application style is importantyou can see wildly successful environments with different strategies:

 Microsoft builds a framework that leverages the power of SQL , row sets, and relational databases The center of the Microsoft universe, from a data perspective, is the relational database The strategy can scale very well and

is surprisingly productive

 Java, instead, seems to be moving toward ORM The center of Java's data universe is an object-oriented, persistent model Other Java applications leverage JDBC with helper frameworks quite successfully

 Ruby on Rails takes an intermediate approach Rails wraps a database table with objects that discover the structure of the database dynamically

All strategies have strengths and weaknesses, and each could serve as an effective foundation for a new language I do think that emerging languages, and the core frameworks they need, should try to follow these rules:

Embrace the relational database

While a language may integrate with alternatives, the relational database should be a first-class citizen Too much focus on object-oriented databases proved to be a problem for adoption for some Smalltalk frameworks Object-oriented databases are an elegant solution that ignores the current political realities

Don't force structure on the relational database

At some level, a language must make it easy to use existing relational

schemas, as they exist Forcing a surrogate unique identifier rather than a composite primary key also ignores existing realities

Perform, and scale

High database performance is the single most important indicator of good application performance

5.2.2 Transactions and Security

Enterprise developers need the ability to define a business transaction It doesn't matter how fast you can build incorrect applications If Joe Bob loses $50 in an Internet transaction because Sally Sue crashed the server by tripping on a power cord, the framework is not going to make it in the enterprise

Security is also important, though you could probably argue over how important it could possibly be with the gaping holes in operating system security today Java has set a bar that's going to be pretty hard to clear in this area The next big

language will need the ability to integrate with existing enterprise security

frameworks, at least the Internet-based schemes and standardized ones like LDAP

Table 5-2 summarizes the enterprise features a new language will need

Table 5-2 Enterprise requirements for a new language

Database access

API Provide a clean, productive API for database access

Relational

databases Focus on relational databases first

Database

performance Database interactions should be very fast

Transactions Enable application transaction demarcation

Language security Provide a clean foundation for language security

Application

security Let developers secure their applications

Security integration Let developers integrate enterprise security, especially for

Internet applications

Like the Java features, having these basic enterprise features does not guarantee success They just let you play the game

5.3 Generating the Buzz

Many languages have trumped Java technically, but they still failed Betamax, too, was technically better than VHS The biggest factor of the equation is social

Without a credible community, there can be no success To a programmer, a

language is an investment in a future, and even an identity Call it marketing, or buzz, or even hype If it's hip, or at least interesting, a language stands a fighting chance If not, there's no chance at all In some ways, Java helped pave the way for the next language:

 Communities like TheServerSide and Slashdot provide a forum for new ideas to spread quickly through the Java and non-Java programming

communities It's much easier for smaller projects to create a big buzz

 The increased emphasis on open source software, partially driven by Java, makes it easier to wrestle control away from larger companies Also, those

same companies find open source technologies easier and less threatening to adopt

 Many Java standards like Web Services (and lightweight HTTP alternatives) make it much easier to interoperate between languages

 The JVM will run other languages A new language on the JVM is a much easier sell than a new language in a new environment

Still, the challenges of establishing a community are daunting Microsoft has spent millions of dollars promoting the NET environment, and the adoption on the

server side is still nowhere near Java's adoption, though many of the features and capabilities are similar or superior to Java Sun, for all of its success with the Java platform, has not been able to capitalize on it in the software realm Adoption of Sun application servers and management software has been spotty at best IBM lost the battle of the operating system because it couldn't market a technically superior OS/2

Programmers are a schizophrenic lot One moment, we're the ultimate skeptics, ditching the safety of the Microsoft Windows environment for unpredictable Linux systems on our desktops The next, we're lemmings, adopting hideous architectures like EJB without the slightest bit of proof You also have many different niches within the programming community Java's been successful for enterprise

developers, but hard-core hackers in the Perl and Python communities frown on Java And Microsoft developers form cultures all their own, with subcultures in it that favor C++ or Visual Basic

That means the winning formula will also change At one point, a dominant

personality like Steve Jobs may make the difference, and the next, like with the star-crossed NextStep platform, it's not enough This is all to say that generating buzz is more art than science, and maybe more luck than art Still, certain themes and trends ring true

5.3.1 Open Source

Unless it's a disruptive technology, it's hard to imagine the next major

programming language coming from a larger commercial vendor There's just too much fear and distrust among the major players: Microsoft, IBM, and Sun Instead,

I think a credible alternative is much more likely to emerge from the open source community The open source model provides a stage for thousands of projects, where they can succeed or fail based on their merits Projects need to prove

effective technologies and marketing amid a cynical, critical audience to succeed

There are several interesting test cases in the open source community now: Perl, PHP, Python, Ruby, and many others You see far fewer commercial languages with any degree of momentum The biggest, C#, is effectively a Java clone

Open source software has something else going for it Since open source projects usually have no formal support, the community must support the language This environment tests the community dynamics for a language as well as the

technology Communities take on a personality, like snobbish, edgy, nurturing, or bickering Larger languages like Java may have subcommunities with personalities all their own When a language gets sudden attention, the personality of the

community will either attract or repel new users Fine-tuning community dynamics

is a difficult proposition, because this personality may be hard to judge from the inside A new language will need an attractive community to succeed, and the open source community seems like a natural place for that to form

5.3.2 Economics

While open source frameworks usually lend a certain intellectual honesty to a project, commercial forces will have the deciding vote A new language needs a supporting ecosystem to thrive, and that means someone has to write a check

eventually Simply put, you can't move away from Java without economic

justification To me, the leading potential economic catalyst is clearan

overwhelming advantage in productivity

When I stepped away from Java for the first time, I needed an economic mother bird to nudge me out of the nest Java's just too safe and too comfortable otherwise Recall that as I write this book, I am calling the shots for a start-up We're writing a Java application to help engineers configure equipment that measures safety

systems in manufacturing plants I recommended moving the application from Java

to Ruby midstream because I found the difference in productivity between the environments too great to ignore Further, when all was said and done, the new application was easier to maintain with fewer lines of code, it was fast enough, easier to tune, and easier to extend with security I'd estimate that we're three to five times more productive in Ruby Certainly, Ruby is not the only language that's more productive than Java, but it's an interesting test case You'll see more in

Chapter 7 Productivity will be the economic catalyst that begins to chip away from the Java base Productivity will drive the emergence of the next great

language

5.3.3 Approachability

When you look at early adoption for all major successful languages, one of the key issues is approachability New languages need to grab new users quickly You should be able to get started quickly, and solve a problem that's important to you immediately C was approachable because it let hard-core systems programmers solve low-level problems in a high-level language, with much better performance and flexibility than other high-level languages C++ was approachable because you could write C without modifications, and upgrade to C++ features as you wanted to include them in your programs Java was approachable because it had a familiar syntax, a friendlier memory model, and a clear, consistent path to Internet

solutions Smalltalk was not approachable, because vendors charged too muchit was too expensive to play

Though nothing simple has a C++-like syntax, I still think that many languages are approachable because of their friendly, productive syntax with a familiar object model Python versus Ruby is a good example of differences in approachability Ruby has one of the most highly productive web environments, and a community and philosophy focused on getting programmers off of the ground quickly and painlessly You can install components easily, often with two or three words, using

a feature called Gems that does the work for you, provided you have an Internet connection Python, on the other hand, has a simple language and syntax, but the web libraries are nowhere near as approachable When you start to learn one of them, you don't find the ready tutorials or community reaching out to help you The Ruby on Rails people understand how to make Rails approachable

5.3.4 The Killer App

Without some kind of catalyst, it's difficult to imagine how a successful

community ever gets started Applets let Java spread to many desktops quickly Developers could embed dynamic content into their web pages in a matter of

hours

On the surface, it seems like a language must have a vibrant community to ever get rich enough to succeed on any scale, but the community usually won't come until the language is rich enough A killer app to a developer is a solution that is so compelling that it transcends language It alone can rapidly drive community

growth It's not the only way a language can succeed, but it's certainly the most likely way

The killer app is a popular notion of a catalyst A killer app solves an important

problem in such a forceful way that users are compelled migrate Think California gold rush People often point to the Lotus 1-2-3 spreadsheet as the killer app that moved businesspeople to Microsoft Windows Meanwhile, the killer app for OS/2 never came For Java, you could easily argue that Netscape made it all possible by putting Java on the desktop of millions of potential developers Applets, or the idea

of deploying applications in a browser, also played a significant role, and it's that concept that morphed into servlets and server-side Java programming The killer app is a seductive idea, because it encapsulates so many important concepts:

 The catalyst, with economic justification, often takes the form of a killer app

 Once a solution is technically viable, a killer app enables a rapid growth to critical mass It often solves a chicken and egg problem: you can't build a sufficiently robust language without community, and you can't build a

community without a successful language

 The killer app often initiates the hype that's required to escape a niche With the newly found hype, the language can explode from a small, focused niche

to a more generally successful language

Remember, a language alone is rarely enough Right now, several interesting

technologies could possibly grow into potential killer apps Smalltalk's

continuation servers, Ruby's metaprogramming environments, and PHP's many applications like bulletin boards may serve as potential killer apps We'll look at some potential killer apps in Chapters 7 and 8

Table 5-3 lists community-centric roles Each of them will come into play when it's time to determine the next major language

Table 5-3 Community-centric roles

Rule Description

Open

source Have a rich open source community

Productivity Be much more productive than Java for the simplest commercial

applications

Catalyst Have a tremendously popular application or framework that

transcends programming languages

Familiarity Be easy for Java developers to learn

Simplicity Make it easy to solve simple problems