The Next Wave

What is Web 2.0 ?

So James recently tagged me (so the next time you read this, I'll have my five things for your enjoyment), but as I was putting some of those thoughts to virtual paper, the following was forwarded to me and I had to share.

There are many opinions as to what web 2.0 is, but this one is one of the better videos I've seen which describe the evolution of the web (which is usually the way I describe it ... not by a version number, but as the evolving web ... and given that it's in continuous evolution, I wonder what a video like this will show 1, 5 or 10 years from now ? Enjoy ... Posted by brewin Feb 03 2007, 06:26:34 PM PST Permalink Comments [3]

Open Source Ghetto

Mark Reinhold pointed the following out to me tonight ... I think it's a good idea, anyone else ? Posted by brewin Jan 12 2007, 05:53:17 AM PST Permalink

iPod Mania

Had to laugh ... this recent article on a new building in Dubai which will be designed to look like an ipod when done. Notwithstanding the fact that the entire building will lean at six degrees (it's on top of a simulated docking station), it just makes me wonder what's next ... perhaps next door the Bose building will be built (with a connecting tunnel of course) ...

Posted by brewin Dec 27 2006, 05:04:36 PM PST Permalink Comments [1]

Web 2005

I read with interest the blog by Dion Hinchcliffe the other day who was commenting on a rather interesting item that may have gone unnoticed by some, and that was the removal of the phrase "Enterprise 2.0" in Wikipedia (and there was, of course, associated fallout).

Ummm .... wow ...

My first thought was along the lines of some of the posts I found online (generally along the lines of "how dare they!") but upon reflection while this may seem like censorship to some, the fact that the term was entered into Wikipedia, updated/edited and then deleted should be what the "writable web" is all about. What may be different about this (and what may cause the furor) is that what we're dealing with here isn't an additive property (more information) but a subtractive one (in this case the data seems to disappear)... and worse, a seemingly arbitrary one.

(Note: the system does work BTW ... nothing is really ever deleted, it just may not be visible ... and the history of the changes are available if you just take the trouble to look)

I looked through part of the debate on the topic in Wikipedia. Fundamentally, it seems that a Wikipedian editor made a decision that the term was not notable enough and did a speedy deletion based on a prior review of the term. What strikes me as funny is the same argument about being a "neologism of dubious utility" (advice to editors: be wary of the term 'dubious' ... its negative and subjective ... 'unproven' in this case might have been more appropriate) could have been applied to the term "Web 2.0" early in it's lifecycle ...

Why wasn't it, I wonder ? Is it that enough implementation existed within the "web 2.0" space by the time the first Wikipedia entry was created ? (and in case you are curious, that was February 28th, 2005). Or do we actually believe that "web 2.0" was really something new ? Probably, but it does raise the question of who gets to be judge, jury and executioner of what's real and what's not. (I note that the following theory is evidently real enough. Cool ...)

The general point then isn't in my mind that the term "Enterprise 2.0" isn't legitimate or real ... it's whether the name as applied means anything to the people who are building or using it. It's just a name. "Enterprise 2.0" is just as real as "Web 2.0" in that sense. That enterprise architecture and set of ideas (for example, SOA, SaaS, dynamic IT and "web 2.0 technologies") that collectively is called "Enterprise 2.0" should be enough.

It should be noted that I personally prefer the application of the characteristic here rather than a version number (a door is still a door, whether it locks, slides, swings, raises, opens one way or two ways). The underlying model arguably hasn't changed, it's more of how we're using it. The difference in this case is primarily at the endpoints or nodes of the web where (for instance) the server can interpret a much richer request. Whether it's the writeable web or read-write web, it's still the web. This sort of definition by characteristics or behavior to me is much more useful ...

That said, I'm not going to get hung up on the name ... common and accepted usage and practice will be enough for me to move forward ... for now ...

Darn marketing hype ... might as well borrow from commercial branding models and just call it "Web 2005" ...

Posted by brewin Aug 22 2006, 10:19:27 PM PDT Permalink

Java and open source ... a quick note

Been very, very busy of late ... the most important is what's happened just in the last couple of days with an update regarding our open source activities for the Java platform. Cast around to find the various pieces of news from Rich Green, Laurie Tolson, Alan Brenner, Simon Phipps, Mark Reinhold, others and myself ... pretty good stuff. Yes, it's harder than most people think (as Geir notes in his blog) ... but it's worth it and things are proceeding. I'll provide more information about exactly what we talked about yesterday in my next post (probably tomorrow ... promise!) Posted by brewin Aug 15 2006, 09:07:54 PM PDT Permalink

The disposable enterprise

Just an interesting observation ... Sun just announced a bunch of new boxes, one of my favorites being Thumper, a four-way x64 server with up to 24 terabytes of storage. Finally, something big enough to allow me to packrat just about everything ... :-)

Seriously, it's an interesting idea where by using next generation file system software like ZFS, you can treat everything you have as just one big volume ... and if a disk drive fails, no big deal ... it becomes the equivalent of a marked off bad cluster on the single drive in your PC. You don't worry about replacing the drive (that's down time), just have it fail in place and leave it there. At some point when you add additional storage and migrate that data off, perhaps then you'll replace it. Given MTBF that may be a while ... so you have what is in essence disposable storage ...

The way things are going, we're fast approaching (and already there in some cases) the point where the computing environment itself is just as replaceable ... if a node goes down, processing just shifts somewhere else. You don't bother to replace or repair that node ... at least not until the impact is felt on the grid, cluster or network that it belongs to. Sending in a repairman just introduces risk ... fail in place is the way to go.

In terms of software of course this means we need to design things differently. Locality shouldn't and can't matter and you see that in the nature of current and next generation software platforms and technologies, where resources (compute, data or otherwise) are allocated from system-wide pools rather than fixed-node ones.

Brings new meaning to the disposable razor (blade that is) ...

Posted by brewin Jul 13 2006, 01:28:41 PM PDT Permalink Comments [1]

The real next wave ...

If you haven't heard, I have a new job ... one I share with Tim Marsland (Sun Fellow and Solaris Guru), and that is of the role of CTO for Sun Software. I'll describe what I do in my next post (Tim likes to say it's "everything that starts with 'J'" ... which is an oversimplification (but it will do). Right now I'm way too busy getting a handle on everything but I expect to be able to get back to blogging within about a week. Until then ... Posted by brewin Jun 14 2006, 08:40:30 PM PDT Permalink

Hell Freezing Over

The title of this article should not be credited to me, but Mike Milinkovich from Eclipse in his blog entry about a contribution to the CVS sourcebase for Eclipse. Honestly, I can't defend the contribution (personal bias) and my only comment about the usefulness of SWT in the context of portability and compatibility is that this sort of change shouldn't be necessary to use Eclipse on Solaris/x86.

Swing works just fine thank you very much.

In my mind, it proves once again that SWT is the wrong solution.

So ... Milinkovich says they won't change the name ... but consider embracing the purity of the Java platform completely by dropping SWT and perhaps the gulf between tools like NetBeans and Eclipse won't be as wide. Posted by brewin May 18 2006, 03:31:13 PM PDT Permalink Comments [10]

Best intentions ...

So I had intended on following up my last post regarding the "next wave" with some discussion about Sun's tools and how they are evolving to solve some for the new architectures resulting from service-based technology and a new ecology. However, I wanted to follow-up instead on my last post as a result of questions posed by some who read it ...

One question dealt with whether the increase in bandwidth might change the granularity of the services and what the effect on productivity might be. Interestingly, it could go either way ... with greater bandwidth it would of course be possible to have many more finer-grained services, however it's my contention that standard engineering requirements and practices will prevail (greater bandwidth will enable a vastly larger number of service interconnects, but that doesn't necessarily mean that the services themselves will become finer-grained).

Essentially, I don't believe that the services themselves would be much different than how we build and deliver stand-alone apps and components today in terms of granularity. We build things at coarser levels of granularity for a reason: they are easier to deliver, test, manage and design (it's also typically a side-effect of the way we organize into development teams, etc.). The difference in these new components is the distributed nature of the applications they are used in ... someone else is providing some of our logic, some of services (from "somewhere"). We have to be able to handle that not only from a deployment/management viewpoint but the development/debugging/profiling one as well.

A separate question was how the services industry will evolve. There are (at least) two models which exist (or will exist) ... the first is the "legacy" folks like SAP who take their large systems and wrap it up as a collection of larger services (what's behind, for instance, NetWeaver / ESA and the delivery of "enterprise services") ... this, of course, is happening today as companies with existing infrastructure migrate to more loosely coupled systems. The second model I believe will be that of service aggregators (as a business).

Beyond the apps-to-be-services today, we will likely first see a massive explosion of smaller services for various functions, but over time things will coalesce around larger service providers (example: travel reservations system, financial support system or supply-chain management) who perform a function of aggregating smaller services and providing the management, risk mitigation ... most of the "ilities" for the apps, consumers or heck, other services which consume them. It will lead to an interesting new business model for the new "Dot Coms" as they take on the task of providing meta-services (and likely by in turn building upon things like the Sun Grid ... why pay for all of that infrastructure yourself when it exists at a low cost-per-hour for use by you and your customer ... ) ... anyone think this could be an interesting new business ?

The short answer here is that it will be rare that someone would build a large application of hundreds of services ... there will typically be a "food chain" of increasingly coarser services that applications higher up the chain will build on.

Existing SOA tools working with services (regardless of granularity) will improve productivity (we are visual creatures by nature ... working at the XML level is, to say the least ... painful), but we still need more in this space. While we do still need additional construction / visualization tools (to work at different levels of abstraction or use-case), productivity isn't just about the "building" side of development ... the whole life cycle needs to be addressed as well (which includes, obviously, deployment, debugging, profiling, maintenance, etc.). Coarser services should help somewhat (less to manage), but there is still a lot missing in terms of infrastructure, architecture, blueprints, best-practices, runtimes (and yes tools). The good news is that we (Sun) are thinking about it and in an upcoming blog I'll describe what we're currently doing as well as where I see things moving in the future.

Next week, of course, is Java One, which will be an ideal time to describe the development landscape and the tools needed for them. So until then, keep looking forward ...

Posted by brewin May 08 2006, 06:08:08 PM PDT Permalink

The next wave of Software - Moore meets Metcalf meets Rock (and don't forget Gilder)

One of the discussions I've been having and ideas I've been promoting as I've traveled around doing various talks at conferences, customer site and universities (this week in Australia / New Zealand) is the notion that we are rapidly approaching an inflection point ... one that has significant repercussions for those of us building and maintaining software in the industry today.

Background

In these discussions, I've been using what were previously considered as hardware-only "laws" and applying the principles behind them to software development. As a refresher, the laws in question are the following:

• Moore's Law - an observation related to chip complexity and unit cost, the essence of which for this conversation is that the number of transistors we can cram onto a piece of silicon is roughly doubling every 24 months. Another way of looking at this is, of course, complexity

• Rock's Law - an observation on what it takes to manufacture those chips. Consider it the economic corollary to Moore's Law and it states that the cost of building those chips doubles every 4 years. As the chips become denser and more complex, the cost of building a new fab plant to manufacture them (as well as all the services including R&D around them) is going up

• Metcalf's Law - this law states that the value of a network is equal to the square of the number of nodes on the network. Simplistic example: if you have one phone, it's value is limited. Add a second (now you can call that other phone), the value of what is now a phone system goes up. Add a third (and so on), the value increases exponentially

One reason for the move towards clusters of lower-cost chips is the recognition and application of these laws as applied to hardware design and the systems built from them. From an economic sense, at some point it makes more sense to not build denser (and more costly) Big Hunks of Silicon(tm), but instead create clusters or networks of lower-cost chips which provide the same functionality but at a lower cost. Although Metcalf was really talking about networks, I believe the same applies when looking at these networks-in-the-small, that is that the value of those compute systems increase to the square of the number of nodes in that network

• Gilder's Law - this law states that bandwidth (the "size of the pipe") triples every 12 months. The implication is that connecting all those systems becomes even more possible and reasonable as the bandwidth goes up (and as a result of Metcalf's law, the value of the network goes up even further as the network can now scale to sizes unachievable before)

Hardware "laws" applied to Software

It is my belief that the principles behind the above hardware laws can be applied to software as well. For example:

• Moore (complexity) - At the coarsest level, the number of components and/or services in any given application or software system is increasing year over year (unlike hardware though it's much higher than double ... the creation and use of components and services in software is inherently easier than in hardware). For the sake of argument I'm assuming that at a minimum, that number is squared (so the number of services or components available in a given software system will exponentially increase)
• Metcalf (value) - Like hardware, the value of the application or system will increase by the square of the number of services or components in the system

• Rock (cost) - The cost of building the network of services (not the services themselves ... we have a pretty good handle on that) goes up as the scale of those service-based systems increases. Simply put, it's taking a larger effort in terms of resources and time to build, deploy and manage larger and larger scale software systems

• Gilder (bandwidth) - As the bandwidth increases, this increases the number of service connections we can allow for in our software systems thus resulting in larger (and more complex) service-based applications.

The evolution of software systems and their complexity

As the software development industry has evolved, we've gradually moved from what were mostly monolithic systems built using structured programming languages (Fortran, Cobol, etc.) to mainstream applications built from collections of objects. These object-oriented systems drove not only OO methodologies and architecture but promoted component re-use ... something which wasn't used as extensively in the Days of Structure (sounds like a movie title ... )

Beyond objects (yes, all you Smalltalk folks will bring up the fact that you were already sending messages ... no offense, but I believe we're moving beyond that here), we are now moving into service-based systems of a scale unheard of in the past. It's not so much the presence of services but rather the complexity which results from the aggregation of these services from sources which frequently exist outside the firewall rather than from within it as with most stand-alone software today. The result is an explosion of services and connections to services scattered across the globe:

So services result in a geometric change in complexity ... obviously at runtime (and there are loads of folks who are building out the enterprise infrastructure to support them) but also at development and maintenance time. Without change, the scale to which these apps can grow is limited (assuming you don't want to live with the consequences of scaling quality and risk aversion as well). Building what I like to think of these new hyper-scaled systems will require a constant evolution of not only the runtime platforms they run on, but the development tools which build and maintain them.

Another interesting analogy between H/W and S/W here is how we at Sun have looked at improving the network, computing and the data center by paying close attention to three principle areas: Availability, Reliability and Scalability. The terms are pretty self-explanatory ... for software:

• Scalability - How big can I scale my system ... and it's no longer just a monolithic application ... who remembers the below chart ? These "applications" (that term needs to be replaced ... I believe applications are now passe´ ... they are services in their own right ) will be BIG ... including everything from "standard applications" to phones, your toaster, RFID tags you name it ...

• Reliability - Can I trust the services I'm using ? Remember, you don't own them ... so the presence of Identity systems, credentials and security are crucial

• Availability - I'm building an app that is dependent upon some service coming from "somewhere" ... will it be there when I need it ? What kind of guarantee do I have that it's a service I can depend on ?

All of this is going to require a new generation of development platforms (that's runtimes and tools) than exist today ... if you look at today's tools, they are actually designed for yesterday's problems (they are designed to primarily solve the structured and object-oriented languages and applications ... we can partially manage new service-based systems with them but fairly quickly now we will exceed their capacity to deal with them).

At the high level some of the changes required to both improve the ease-of-development experience in modern applications as well as to deal with increased complexity can be captured in the following:

• Languages and platforms. Extend the capabilities of the languages and platforms such that they enable easier (and less risky) development practices. The changes made in the last few years in the Java platform are prime examples of that type of improvement. For example, the use of annotations to allow for more declarative programming as well as removing the requirement for explicit specification of complicated metadata that previously had to be hand-coded. This (obviously) simplifies development but also reduces the risk for silent errors in code that have to be dealt with upon deployment and maintenance. Similarly, other changes like the addition of enumerations and other language features to the Java language reduce risk and improve the development experience

• Deep knowledge. Use the deep knowledge available to compilation, tools and runtime environments to improve the reliability of applications running on the platforms and networks. For instance, inversion-of-control changes in Java EE 5 (by this I mean letting the container do what work it can for you so you don't have to) will greatly increase the reliability and ease the development process (look, for instance, at the advantages that a system that manages persistence for you can do)

• Adaptive environments. Different tasks require different tools. Different users are using those tools. Depending on the task or the audience (or both), the tools should adapt accordingly. The simplest example ... if I'm building a web service, why do I need the GUI design tools at my fingertips ? They clutter my desktop and detract from the user and development experience. Which leads me to the next point ...

• Abstraction. As part of adaptation, use abstractions to allow for highly effective visual and non-visual modeling and development during the process of building, deploying and maintaining services and systems of services / applications. For example, while working against the same common model (my code), I should be able to work within:

A specifications view

A graphical programming view

A pattern view

A UML view

A code view

A packaging / assembly view

A business process model view

And so on ...

The general alignment with adaptation is not only should my tool adapt to my task or type of developer/development, it should provide the optimum view of what is under development at a given time ... if it's most efficient to "code" using a UML model at a specific instance in time, do so ... if I'm modeling the process, use a business process tool ... if I need to get my hands dirty let me at the code.

• Development Process. Lastly, encompass the entire development process (not just compile-edit-debug). This means, at least in part, Application Lifecycle Management (ALM). Being able to build services and systems of services using well-established processes (and pick your methodology ... which one isn't important, only that you have one) which go from requirements, to specifications and all the way to end-of-life are crucial as the ability to deliver predictability in both the development process and the end-result is a must when systems go hyper-scaled ... the results of not building these highly-scalable, highly-reliable and highly-available software systems properly will be extraordinarily expensive to fix once deployment begins.

Next time I'll "go product" (or at least "go technology") and talk a little bit about how we (Sun) are working on the next phase of "attacking complexity" within the development platform space. I would, of course, be interested in observations, criticism and real-world stories where building to the next generation system have caused a new way of looking at the computing world. Posted by brewin Mar 30 2006, 02:04:42 AM PST Permalink

On the road down under

I'm on the road again, this time "down under" ... visiting Sydney, Melbourne Australia and currently in Wellington New Zealand. So far, it's been rather exciting as I've been meeting a number of developers who have certainly not been shy in coming to talk to me about technologies, Java and sometimes problems they are trying to solve (and wondering what Suns' position or plans are in areas which are causing them pain). This is great stuff ... one of the reasons I really love going on the road is that I learn more in a couple days on the road meeting real live customers than I do at home because these folks are solving real-world problems which I can then take back into Sun as feedback.

Getting here was a bit of a problem as (if you haven't heard about the weather) as there a number of cyclones in the area which are causing air traffic problems in areas such as north-east Australia and here in New Zealand ... I'll leave that story for another time.

After my keynote here in Sydney Brad Perriott, one of the local Sun folks, picked my up by car and took me to one of his favorite local breaks near the town of Mona Vale near Sydney.

Having seen pictures in the local paper from the day before of waves kicked up by the nearby cyclone, I was looking forward to a serious work out.

When we arrive, the weather was warm, there was almost no one out in the water (which was around 22C) and the waves were around 2M and clean ... we surfed for what seemed like days and at the end of the day we couldn't raise our hands over our heads because our shoulders were on fire ... good thing beers don't have to get hoisted that high.

.....

OK ... not really ... (over a beer at the end of our surf session, I thought about exagerating the truth a bit, but after reflecting last night I figured that anyone who was a real surfer would have just checked one of the local surf sites and realized I was pulling their legs ... sorry Brad ... couldn't go through with the "fish story" :-) )

Everything was as above, but the waves were about 1M and mushy ... so much for the epic cyclone-driven waves but it was still a lot of fun ... I've surfed in various places in the U.S., Costa Rica, Nicaragua, Hawaii, Mexico, etc. ... never Australia (so this was a real kick). One thing to be said for the folks here in Australia is that there is a real sense of "stoke" related to surfing and pretty much everyone I've met is easy-going, nice and I didn't get any feeling of the kind of local-ism that you get at some other places like Hawaii and some breaks in California.

Here's some thanks to Brad and team for allowing me the opportunity to sample some great Australian waves and hospitality ... this weekend I'm off to go wake boarding on one of the local rivers here (and I'll let you know how that went) Posted by brewin Mar 28 2006, 11:39:18 PM PST Permalink

Back at the Ranch

Just came back from vacation (North Shore of O'ahu). Rained pretty much the entire time I was there but the surf (of course) never stopped and my wife and I had a pretty nice time. For those familiar with the breaks, we spent most of our time at Haleiwa, Puena Point and Chun's Reef (our personal favorite).

Wave size was actually in the "human" range this time around (at times when we go, the waves aren't really suitable for mere mortals ... certainly at places closer to Sunset Beach). This time, the waves averaged between 2-4 feet about half the time and 4-8 feet the rest. Hawaiian scale of course ...

For those that don't know, surfers in Hawaii measure waves from median sea level to the crest (look at the wave from the back to get an idea). Weather service forecasters on the other hand measure the front of the wave (from the trough at the front to the top of the wave). So a non-Hawaiian wave measurement is about 1.5 to 2 times more than the same Hawaiian wave (so my earlier measurements in the rest of the world would be at the low end, a 4 foot face up to about a 16 foot one ... and those were fun :-)

Anyway ... back to the "grind" ... and it will be a busy time indeed. A lot of travel coming up, including the Developer Days conference(s) in Australia and New Zealand starting at the end of March in Wellington and Sydney followed by a date in Melbourne the beginning of April (and yes, I hope to get some surfing in while I'm there).

If you are a developer, whether on the Java Platform or Solaris (or both), go to the site and register ... it's free and will give you a chance to hear from a number of speakers on a huge range of technology choices and also give you a chance to interact with other folks in the Australia and New Zealand developer communities.

I'll provide a little mode detail as I get it, but check it out! Posted by brewin Feb 26 2006, 12:53:47 PM PST Permalink Comments [1]

Taking over the world !

Well ... that may be extreme ... but I was reading with interest the following blog which seems to indicate that Netbeans is generating a lot more buzz and in this experiment involving search volume on Yahoo, shows Netbeans beating Eclipse. As I stated in a comment on the blog, it may not actually be that unbelievable. Netbeans usage (active users which is the only real measure that means anything) has more than tripled over the last year. Without having the actual Eclipse numbers, it's hard to tell (and as far as I know, they don't publish those but rely on the buzz as a popularity index ... which if the study is true may mean it's a closer horse race than most folks expected. Posted by brewin Feb 07 2006, 10:51:28 PM PST Permalink Comments [1]

Hush-a-boom

There are many examples (or at least cliches) about (and here's one: "it will happen so fast, you'll never see it coming") how something which should be obvious gets lost in the noise (there's another one). Technical or product innovation or adoption is another example of this.

Jay Ward (the creator of the Rocky & Bullwinkle cartoons) had another one: the hushaboom. In the segment "Banana Formula", Professor Bermuda Schwartz invents a silent explosive called "Hushaboom" (cool stuff, it explodes but makes no noise).

I look at Netbeans as an incarnation of Hushaboom ... at least where other IDEs such as Eclipse are concerned. There is so much hype about Eclipse that what seems to be lost is the gains that Netbeans is making significant advances, both in functionality and adoption within the Java development community. If it were a snake, it would bite you in the ... (never mind, but that's another one).

The point is that release after release, Netbeans continues to push the envelope on development environments, improving it's performance, it's capabilities and the size of it's audience (and quite a loyal following it is). Why is that ? A number of reasons, but I like to think one of the key contributors is focus ... focus on improving the architecture, focus on delivering the needed features rather than attempting to be "an open and extensible IDE for anything and nothing in particular". Look at the set of awards from folks like Developer.com and Sys-Con. Netbeans isn't just Netbeans, it also includes as part of it's family, tools like Sun Java Studio Enterprise and Java Studio Creator. Year over year, the popularity of Netbeans continues to rise.

Competition is good ... it forces innovation and improvement. Others seem to agree. I recently replied to a small piece of a Dana Gardner blog entry (apologies for the title of that response ... a rookie mistake ... I neglected to change the subject line before hitting which was written in a moment of passion :-) ). The response itself I stand by ... Netbeans is rapidly catching up and applying pressure to Eclipse ... this is a good thing, both for Netbeans (obviously) and Eclipse very likely. And it's possibly not just Eclipse either who is benefitting from healthy competition...

Remember ... "You always have to watch out for the quiet ones ..." Posted by brewin Jan 17 2006, 10:19:54 AM PST Permalink

If all you have as a hammer ...

One of the questions I (and others) get hit a lot with is "why 3 Java tools?" (they are speaking specifically about Netbeans, Java Studio Enterprise and Java Studio Creator). It's perhaps worse now that all three are Free.

The answer is partly historical, and part just about focus and alignment. The tools are designed, created and delivered for developers who need to solve specific problems for (in many cases) specific runtime platforms. Take Netbeans for example. Netbeans is the open source IDE (upon which all of our other tools are built) which is aligned very tightly with the standard Java platform APIs and runtimes (specifically Java SE and Java EE). It is there for experienced developers who need to have an IDE which is tightly bound to the Java platform and RIs (including the latest and greatest implementations approved by the JCP).

Java Studio Enterprise on the other hand is tightly aligned with the Sun Java Enterprise System stack and the needs of large enterprise applications who are building composite applications leveraging a Service Oriented Architecture (SOA).

Java Studio Creator is all about new developers to Java or domain experts ("corporate developers") who need to build rich web applications using JSF and consuming services and data which exist on their network.

(Yes ... and if you look deeper into our tools portfolio, you'll notice that the Mobility tools are aligned with the J2ME platform and Sun Studio with the needs of native developers ... it actually does make sense)

The remaining question is will they stay that way ... probably not. The lines between the differing application platforms are becoming blurred (this is a normal tendency in our industry) as the need to leverage technology in what were separate areas becomes commonplace. For example, you may want to add mobile access to your enterprise application (so you want Mobility tools in your Java Studio Enterprise product) ... or you want rapid web application design in your Netbeans or Enterprise tools products. By the same token, just smashing them all together doesn't make sense either ... the result would be likely a schizophrenic tool with a convoluted or confusing workflow, UI or development paradigm. So will this change ... yes, but incrementally and with some forethought. It's already happening (look at the Developer Collaboration tools which used to be the domain of Studio Enterprise ... they now exist in Netbeans as well).

So look for more integration as we move forward, but at least now you know that you can easily get one or all of the tools (for free) that you need for the specific task at hand (the old adage about "if all you have is a hammer, everything looks like a nail" comes to mind ... that isn't a good thing). You frequently need the right tool for the job and in the Sun and Netbeans portfolio, the right tools exist today for your use.

Posted by brewin Nov 09 2005, 09:35:56 AM PST Permalink