J2EE Automation ISV AltoWeb Closes Its Doors

Discussions

News: J2EE Automation ISV AltoWeb Closes Its Doors

  1. J2EE Automation ISV AltoWeb Closes Its Doors (11 messages)

    AltoWeb, producer of J2EE and Web Services automation software, has apparently closed its doors. CRN actually visited the Palo Alto headquarters, finding a gutted location.

    Does this show that there isn't as large a need for these kind of ease of development tools? Forrester attributed the alleged demise to the maturation process of J2EE, which in the challenging economic climate, "makes it hard for companies other than the big players to survive."

    "I think that the going out of business of companies like AltoWeb is an indicator that consolidation is moving toward the large vendors," Meyer (Forrester) said. "Companies like M7, Bowstreet and others are going to have a hard time surviving in the future, especially when the other vendors have an entire stack to offer."

    Meyer also hinted that because large vendors will be providing Java software in the future, J2EE will continue to be limited to enterprise deployments and not have an easy time successfully branching into the midmarket or to departmental-level deployments, as companies--such as IBM with its WebSphere Express offerings--have been hoping to do.

    Consilidation is ripe. Who will be next?

    Read the analysis of:
    J2EE Automation ISV AltoWeb Closes Its Doors
  2. Products like AltoWeb and M7 usually only have a limited life at best. As the lower level services become commodities the vendors usually try to move up stream. As the app-servers became comodities IBM, Oracle nd BEA look to add-on value so we see portal servers, web service frameworks, etc. AltoWeb and M7 "business infrastructure and workflow engines are next. This has been in BEA's plans for 3-4 years (that I know of).

    AltoWeb and M7's only viable plan was to have a killer product, make a big splash, get some market share and then sell themselves and their technology to one of the big fish. It would have been very hard for them to survive as an independent.
  3. The only surprise I had, why Altoweb took so long to close it's doors as they were making the same mistake over and over as other long gone startups did, which is misjudging their market position with respect to their pricing strategy. There is much to learn from evolution of jBoss as a top notch platform which is a sure hit because of zero price combined with ultimate architecture and now is their time to cash in on selling services around the wonderful platform they have presented to the J2EE world. I could just wish AltoWeb would not have suffered from the myopia while positioning themselves in the J2EE market.
  4. Or it's just my sub-par internet connection...

    Did anyone else notice that they had nobody with a clue last year @JavaOne working their booth?
  5. At TheServerSide Symposium it seemed to me like it is the new trend for all big companies to produce J2EE and Web Services automation software. Novell, Oracle, Bea and Compuware have presented their tools which are based on BPEL4WS or use a MDA approach (Compuware OptimalJ).

    I really was not impressed :-) As Scott Ampler pointed out, 15 years ago CASE was the big thing in IT and wanted to make programs be made by making some bubbles and clicking on a button (I had to use the tool at university and that didn't impressed me either).

    My experience is that code generating tools like that are good to make rapid prototypes, but if it comes to non-functional requirements like performance and the code has to be optimized, than the tools don't support you anymore and you have to understand the generated code (which is no fun) and maybe rewrite it totally. I had this experience with a GUI designer for Swing and I ended up rewriting it in Emacs...

    So today I am happy with Eclipse and some supporting tools like XDoclet or XMI based code generators that help me to get my design in class skeletons.

    What is your experience with these click-this-button-and-get-your-enterprise-portal-tools?

    Mirko
    :wq
  6. Aquistion[ Go to top ]

    Its a shame for altoweb for not making itself ready to be bought by majors like novell
    With java's future iam not much confident that it can maintain its lead in enterprise market.
    This Liberty alliance has to be quotes ad Liberty Rich Alliance
    All companies are dying for money --bundling their products ,
    the same Msoft did years ago.
  7. At TheServerSide Symposium it seemed to me like it is the new trend for all big companies to produce J2EE and Web Services automation software. Novell, Oracle, Bea and Compuware have presented their tools which are based on BPEL4WS or use a MDA approach (Compuware OptimalJ).

    It would be nice to see tools and technology that one day actually help us design and implement better software. Just about every tool out there (despite the marketing propaganda) is mostly concerned with just supporting the latest technology; meanwhile, we still have the same old problem - most developers (through inexperience) create bad software. Forward engineering MDA tools and other three letter acronym-based tools (and monolithic, proprietary frameworks) will not help us here. If only the big guns would realize that trying to generate everything for the developer (and alarmingly, non-developers) is a fruitless exercise.

    Help developers create better software - that's the ticket. I'm sure small product companies will dominate this untapped area of growth.

    Regards,
    Bill Willis
    PatternsCentral
  8. Help developers create better software - that's the ticket. I'm sure small

    >product companies will dominate this untapped area of growth.

    It would be good :-)

    Dmitry Namiot
    Coldbeans
  9. MDA != CASE | Code Gen | RAD[ Go to top ]

    <Mirko>
    At TheServerSide Symposium it seemed to me like it is the new trend for all big companies to produce J2EE and Web Services automation software. Novell, Oracle, Bea and Compuware have presented their tools which are based on BPEL4WS or use a MDA approach (Compuware OptimalJ).
    </Mirko>

    Agreed. I think the trend is really to simplify J2EE development. This is to address a growing skills gap in the J2EE market. A large percentage of new entreprise development is being done in J2EE or .NET. This means that more and more legacy programmers (e.g., COBOL), are being retrained to program on the new platforms. As the number of developers grows, the level of sophistication in the aggregate is going to drop. So, us tools developers are trying to simplify J2EE development so that these new developers can be productive.

    <Mirko>
    I really was not impressed :-) As Scott Ampler pointed out, 15 years ago CASE was the big thing in IT and wanted to make programs be made by making some bubbles and clicking on a button (I had to use the tool at university and that didn't impressed me either).

    My experience is that code generating tools like that are good to make rapid prototypes, but if it comes to non-functional requirements like performance and the code has to be optimized, than the tools don't support you anymore and you have to understand the generated code (which is no fun) and maybe rewrite it totally. I had this experience with a GUI designer for Swing and I ended up rewriting it in Emacs...
    </Mirko>

    It's fair enough to not be impressed with the tools, but I don't think it's fair to lump MDA tools in with CASE tools, code generators, and Rapid Application Development (RAD) tools. I'm trying not to be overly sensitive, because I know that you didn't really get a demo of OptimalJ, just a preview of a soon to be released case study from The Middleware Company. But there is a lot of confusion on this point, so I want to point to some differences:
    1. Everything is standards based. The models are defined in UML and persisted in XMI. Therefore, you're not locking yourself into the tools vendor. Even the process is defined in MDA, which is owned by a standards body. The code that OptimalJ generates is standard J2EE. The patterns that we use have been looked at by Sun PS, and verified to comply with the Core J2EE Patterns.
    2. It's a pragmatic application of MDA. OptimalJ doesn't preclude a developer from writing code. It just automates the building of the infrastructure. Rather than implement a Struts front-end, DTOs, EJBs/DAOs, an architect selects the patterns that he wants to use, weaves them into a pattern framework, then uses the tool to automatically translate the Domain Model into an application that uses the selected patterns. But there is still development to be done, the coding of business logic, the customization of the front end, etc. So to use OptimalJ, you still have to be a craftsman, just less of a plumber, and more of a sculptor.
    3. It works in an iterative development cycle. There are constructs that enable the "infrastructure code" to be guarded in the IDE. This means that any changes in the code are preserved when a change is made to the model and the infrastructure is regenerated.
    4. The transformation process is a white box. The patterns that are used in OptimalJ are completely open to be extended or replaced by an architect if they so desire. Lack of flexibility is a large reason why CASE failed, IMO.

    <Mirko>
    So today I am happy with Eclipse and some supporting tools like XDoclet or XMI based code generators that help me to get my design in class skeletons.
    </Mirko>
    In essence, MDA tools are "XMI based code generators". OptimalJ, for example, allows you to visually model your class diagram, persists it in XMI, then uses that structure to generate code based on the patterns you select.

    There's a good article from Stefan Tilkov on MDA here on TSS that you might want to check out, too.

    Regards,
    Mike Burba
    Compuware OptimalJ
  10. MDA[ Go to top ]

    The problem with MDA (as a standard/specification from OMG and any other standards from such an organization) is that they do not give a you a free reference implementation. This is actually the biggest advantage of Java as a platform. Sun + JCP do not only give you the specifications but they also provide you with free reference implementations + test suites of those specifications.

    So, in MDA world each vendor can implement MDA as free as they like. This has happened in CORBA world. I would like to know, whether there are organizations already used MDA with tool X and then they changed into tool Y without any modifications or problems. The compatibility problems begin already in your UML diagram tool, if you want to change to another UML tool for example.

    Without any free reference implementation of MDA from OMG (just like J2EE reference implementation from Sun), MDA won't get any further, IMO.

    At the end we always need a "language" to write our application. The question is:
    - Will MDA (Top - Down approach) be our language? If so, everything will be done in UML, OCL, etc. You model your PIM and transform it into your PSM. In couple of years maybe you just build your PIM and you don't care about your PSM, because you can compile your PIM directly into a running application (you also don't care anymore in what language your application will be running, so you don't have to implement your application in Java anymore, you just have to use UML more precisely).
    - Or maybe Java (Bottom - Up approach -> see meta data, Together's approach, Sun's research projects) will be our language? Is visualization just one of the many aspects in Java? Using tool like Together can make this really real. With many extensions to Java, we will see that Java as a language will become very highly abstracted from the maschine. We already see this with GC, VM. Now the coming meta data, etc.

    At the end of the day, all we want is simple higher abstraction level to write our application, as the history always tells us. So let the competition begins!

    Regards,
    Lofi.
    http://openuss.sourceforge.net
  11. MDA != CASE | Code Gen | RAD[ Go to top ]

    \Burba\
    Agreed. I think the trend is really to simplify J2EE development. This is to address a growing skills gap in the J2EE market. A large percentage of new entreprise development is being done in J2EE or .NET. This means that more and more legacy programmers (e.g., COBOL), are being retrained to program on the new platforms. As the number of developers grows, the level of sophistication in the aggregate is going to drop. So, us tools developers are trying to simplify J2EE development so that these new developers can be productive.
    \Burba\

    This is entirely contrary to my experience. The myth of the old COBOL programmer get retrained is a strong one, but also more a pretext than reality.

    The real problem is the staggering number of people with little aptitutude or experience for software development who got in it for the money in the mid-to-late 90s. In very general terms, people who've been in software for 10 or more years (_any_ kind of software_) are vastly superior to those I've seen come down the pike in the past 5-7 years. And I don't necessarily mean it's about experience, or youth vs. grizzled veterans. It's more a reflection of a culture that looks for the quick fix and laughs at people who attempt to learn deep knowledge.

    Most developers these days - not COBOL programmers, but people who learned Java as a first or second language - don't know how their tools and technologies work, and couldn't care less. There _are_, of course, good young people in the mix, but the sheer volume of the incompetent to mediocre is overwhelming them.

    In other words, there is no problem of retraining COBOL programmers. The true problem is developers with 1-5 years experience who haven't a clue what they're doing, don't really have a developer's mindset, and who love making alot more money as a programmer than in most other fields they're qualified for. And no matter what tool you throw at those sorts, it's not going to matter. A bad developer, like the majority of the dot-com crop we have to live with today, are going to create bad software no matter what we try to do as an industry.

        -Mike
  12. MDA != CASE | Code Gen | RAD[ Go to top ]

    Everything is standards based. The models are defined in UML and persisted in XMI. Therefore, you're not locking yourself into the tools vendor. Even the process is defined in MDA, which is owned by a standards body. The code that OptimalJ generates is standard J2EE. The patterns that we use have been looked at by Sun PS, and verified to comply with the Core J2EE Patterns.

    I'm happy to hear that you are making use of patterns, although I'd like a bit more information on exactly how you are using them. My experience is that most product companies just use them as a buzzword to sell more product. Regarding XMI, it is not really supported the same way by any single vendor (even though there is a standard specification for it). As I have said earlier, it is a real pain to move a UML model from one tool to another via XMI. I don't recommend it unless you have a long weekend to spare...

    It's a pragmatic application of MDA. OptimalJ doesn't preclude a developer from writing code. It just automates the building of the infrastructure. Rather than implement a Struts front-end, DTOs, EJBs/DAOs, an architect selects the patterns that he wants to use, weaves them into a pattern framework, then uses the tool to automatically translate the Domain Model into an application that uses the selected patterns. But there is still development to be done, the coding of business logic, the customization of the front end, etc. So to use OptimalJ, you still have to be a craftsman, just less of a plumber, and more of a sculptor.

    Since MDA has become an overloaded term these days, do you support the OMG's vision for it or something else? The thing that concerns me about most MDA efforts is that they involve primarily forward generating tools. In other words, they don't allow a developer to refactor the design (at higher abstraction levels) based on changes to code. If a change must be made to the design, then you've got to do it in a UML model first and then let the tool regenerate stuff for you. That is counter to the way software is developed in teams! So much for being a craftsman...

    The transformation process is a white box. The patterns that are used in OptimalJ are completely open to be extended or replaced by an architect if they so desire. Lack of flexibility is a large reason why CASE failed, IMO.

    I would like to hear more about this extension process. Most MDA tools are forced to generate to a specific framework (like Struts) and don't give you the flexibility of choosing your preferred technologies. This helps keep things manageable (otherwise, decision points multiply exponentially), but it limits flexibility. So for developing to a specific vendor's software stack and a particlar technology platform, I think MDA is okay (if you don't mind vendor lock-in). Otherwise, I see it as being too restrictive. Add to this then fact that most MDA tools appear to be forward generators only, and I think they will follow CASE tools onto many a dusted shelf.

    Bill Willis
    PatternsCentral