Where are all the components?

Discussions

News: Where are all the components?

  1. Where are all the components? (42 messages)

    In a recent editorial entitled "Where are all the components", author Joseph Ottinger comments on the lack of components and how it is wasting our time and restricting java's growth. In personal weblogs, Cedric points out that components are here (but in a different form), and Anthony Eden blames lack of tools and component repositories.

    Read Where are the components?, Cedrics response, and Anthony Eden's comments.

    What do you think?

    Threaded Messages (42)

  2. Having been watching this issue closely for the last 4 years I have to disagree with Anthony on the points that lack of tooling and lack of repositories is why the enteprise component marketplace has failed.

    There have been component repositories: Flashline.com and componentsource.com were among the first pioneers. Flashline ended up switching businesses when all the component hype never turned into a reality. There were also a couple of developer portals about components (beansforbusiness.com and another I can't remember) that ended up also dieing due to lack of interest.

    Many vendors have invested in making their EJB tooling more 'component like', and many have gone out of business (altoweb is one recent example).

    In response to where are the components, I have to agree with Cedric, they are here, but not in the form Sun initially expected them.

    What turned out happening is that the industry realized that you simply can't reuse business logic across projects. Business logic is always unique to the project, even the notion of a "user". As Martin Fowler says, "the object model IS the application", thus, the notion of an enterprise component marketplace simply never panned out.

    Sun's plan in the beginning was to copy the success of the VB component market and make it really easy to write J2EE projects due the realization of massive marketplace of business components that would save everyone time. Unforuntately, I think they failed to notice that even the VB component market was full of utility and system type components, not business logic.

    Since EJB was primarily intended as a business component specification, it comes as no surprise then that there aren't any business compoents, rather, what we have are many utility and system components, which take the form of appserver services, open source projects, etc...

    Floyd
  3. I think Floyd nailed it.

    In my experience, business applications fall into two categories: Business Software Packages (SAP, PeopleSoft or tools like QuickBooks at the small end of things) and Totally Custom Software. There doesn't seem to be anything in between, and for a good reason. There are simply too many interdependencies between the business processes to come up with a coherent set of functionality that covers a useful subset of your business logic.

    Security plays into your user model which plays into your customer model which effects how you manage order which ties into your inventory system. Each component has to make some assumptions about the other components. You pretty quickly realize that if you are going to offer business components you pretty much have to offer an entire shrink-wrapped package.
  4. To me this also raises an interesting design issues.

    A lot of projects place all logic that works accross component areas Stateless EJBs (Session Facade). For me one of the main reasons stated for doing this is that this makes your business components (Entity EJBs) re-usable. If this is not a real concern then is is better to let your business components talk to each other rather than extracting this logic out.

    David
  5. If this is not a real concern then is is better to let your business components talk to each other rather than extracting this logic out.


    I kind of disagree here, I think EJB offers more than this. Think of scalability and clustering, different accessing methods (transparent HTTP access in JBoss for instance), etcetera...

    I've done quite a few probjects with EJBs, and also quite a few without them... I still think the facade approach pays off, both for the possibilities it adds and (strangely enough) also for the improvement in development efficiency...

    Alef
  6. Also realize CPAN is free, while a lot of components on for instance Flashline weren't/aren't...

    Do managers know about Flashline? Well, in my last job mine at least didn't... Did I know about Flashline, yeah I did, but I did not wan't to buy that does not completely fulfil my needs (while from a business perspective maybe it would have been the best thing to do).

    I think it's also got to do with the last 5-10 years. Money all over the place, it did not really matter if it took five month or 3 weeks (at least, not as long as a competent manager did not know about it). And afterall, we were all busy spending our time on new tech. and that's what a developers wants, isn't it...
  7. Where Is the Flashline Marketplace?[ Go to top ]

    Has Flashline stopped seling Software components ? Their home page has no mention of the marketplace !
  8. Where Is the Flashline Marketplace?[ Go to top ]

    The flashline component business is now served by componentsource.com as far as i know.
  9. Components[ Go to top ]

    The first I was introducted to components was Visual Basic and ActiveX. It was simple, straight forward and most importantly easy to use.

    I think that the difficulty with Java and component building is that the interfaces to seemingly simple things are presented in a very complex way. For example, the JDBC Rowset implementation recently released Draft 2 with 5 implementations.

    it is nice to be able to twist all the knobs and buttons, but not at the expense of ease of use. The purpose of a component after all is to hide the complexity, not to present it!

    Usually, I end up applying some pattern such as Fasade or Composire to hide the complexity. I belive that this should be done by the component builder and not by the developer (which cuts away at much needed development time).
  10. I kind of disagree here, I think EJB offers more than this. Think of scalability and clustering, different accessing methods (transparent HTTP access in JBoss for instance), etcetera...

    >

    How do EJBs make things more scalable, exactly? And, if you're using Local interfaces and Stateless Session Beans (which is the most performant and common usage scenario) then how is clustering effected? With Local components, calls must stay in the same JVM. Clustering can be done at the Servlet Container layer.

    I keep seeing people chanting this "scalability and clustering" mantra about EJBs, but I fail to see the actual advantage. We use SLSBs at work, and I fail to see the advantage (although I could write pages about the disadvantages).
  11. I kind of disagree here, I think EJB offers more than this. Think of scalability and clustering, different accessing methods (transparent HTTP access in JBoss for instance), etcetera...

    > >
    >
    > How do EJBs make things more scalable, exactly? And, if you're using Local
    > interfaces and Stateless Session Beans (which is the most performant and
    > common usage scenario) then how is clustering effected? With Local
    > components, calls must stay in the same JVM. Clustering can be done at the
    > Servlet Container layer.
    >
    > I keep seeing people chanting this "scalability and clustering" mantra about
    > EJBs, but I fail to see the actual advantage. We use SLSBs at work, and I
    > fail to see the advantage (although I could write pages about the
    > disadvantages).

    Yeah, same here. If you use load balancer (with sticky sessions if state is used) then you don't even need the J2EE server to support clustering. If you want session fail-over then you might want session replicating (btw, there are other methods todo this). Other then that, I don't see why you even need EJBs. You don't need remote access to the EJBs most of the time. And when you do, there is web services which is cross-language.

    http://www.freeroller.net/page/grom/Weblog
  12. The component repositories which did exist clearly were not the best solution. Perhaps it was lack of marketing (although I don't think that was the issue for Flashline) or lack of developer buy-in (which is probably more likely) or maybe even a poor user experience (i.e. poor UI, difficult to use, etc). Clearly component repositories can work - just look at CPAN. What is CPAN doing that these other repositories did not do?
  13. CPAN lives in a different world[ Go to top ]

    A few people ask why we don't have a CPAN in the Java world. I think it is more to do with the culture.

    In the Perl culture, everything mainly revolves around CPAN. CPAN is kinda like javax in some ways... it is felt of as almost extensions to the core that you can choose to use.

    The Java community is totally different. There are many more competing vendors, and people don't seem to band together in the same way that the Perl community does. In some ways this is a problem, as if we stop fighting with eachother, we can turn and fight other "enemies" :)

    So, we don't have CPAN, and I don't think we ever will. However we DO have many mini-CPANs with great code (Jakarta, OpenSymphony, Codehaus, and even the mixed bag of sf.net). There are tons of components out there, but it is just a LITTLE harder to find them, and you have to spend a bit more time on choosing components, but that could be considered a good thing too I s'pose.

    I have seen large projects that use a million open source jar files, and keeping dependencies in check is a real challenge (compounded when you have to run in multiple app servers, with multiple JVMs, etc). I guess this is where tools like Maven will try to help us, but there is still a burden that we have to carry.

    Dion
  14. CPAN lives in a different world[ Go to top ]

    I've been thinking about this very topic a lot recently. I began my career as a Perl developer, and you're exactly right--CPAN is the total center of the Perl universe. I think there are three reasons for this.

    1. The components are, for the most part, utterly tiny, or at least have an utterly tiny set of functions/methods you call to get them to work. Instead of commons-net, for example, you have Net::Ftp. Things "feel" light, whether they are or not. This makes you more inclined to use them freely. There's a cultural expectation that the SYNOPSIS section of the documentation will give you everything you have to know to use the component. There's also a wonderful cultural disregard for performance that is born from the fact that typically perl scripts and shell scripts don't have to perform at ridiculous speeds. The nice thing about this is that you tend to just grab a component and not worry about how it's implemented as long as it does what you want in a reasonable amount of time. As I said, I regard this as a good thing. Java comes from the...the...C side of things, I guess, where there has always been a focus on the internals, the guts, how fast things run, etc.

    2. The components are named in totally straightforward ways. Instead of names like "plexus" (I have nothing against this project; just selected it at random), there are names like HTML::Parser. You know basically what the components do without having to crack open a jar or zip file or documentation set.

    3. Massive marketing and shepherding. Anyone asking a Perl question, or claiming to have written fancy new code, is challenged with, "Did you check CPAN first?" This is where the culture comes in: it's "cooler" to assemble a program together out of ugly but working parts (kind of like Perl itself!) than to write it from scratch. Good looking Perl programs (are there such beasts? :-)) are typically headed by a bunch of "use Module;" commands, and consist mainly of gluing the used modules together to get the job done.

    So how do you do a CJAN that smells like Java but works like CPAN? I think you have to address several issues.

    1. Somehow convince open source component writers to release tiny packages, tiny projects and tiny jar files. Refactor mercilessly into small granules. With Perl or shell scripting, the file is the basic unit of release; we would need to approach (but obviously never reach) that level of granularity.

    2. Nice-to-have: have a compiler that could somehow magically figure out when you go to build something that it needs to pull down classes/packages X, Y and Z, much like the CPAN.pm module in Perl.

    3. Stick with an enforced separation, where possible, between interface and implementation. Components in the CJAN would be expressed in terms of interfaces. A preference mechanism to allow a user to (automatically?) select the kind (or the specific type) of implementation would be nice.

    Maven does some of these things, some better, some worse; some sludgily, some elegantly. It's not there yet, though.

    Just brainstorming,
    Laird
  15. Having been in the J2EE enterprise component business for
    the past three years providing EJB components suites for a number of
    business domains such as eCommerce, CRM, Content Management and Indentity Management, I feel compelled to comment here.

    The marketplace that Sun and repositories such as Flashline.com envisioned has not materialized. There are a number of reasons for this. For one, selling business objects to corporations on enterprise class applications is very different then selling component based utilities that are seen in VB market. The evaluation and sales cycle for buying business components is similar to that of buying other software applications that are aimed at enterprise customers. These customers are not going simply order CRM Components from a website. A second could be a lack of market or creating the necessary awareness for such repositories to exist. A third could be a lack of depth in
    the market providing suitable components.

    It would be grossly incorrect to say that business components do not exist
    or that they cannot be built. It is true that business rules and attributes
    vary from business to business and in large organizations, they may vary
    from one business unit to another. When we designed our EJB framework, it was
    with the intent that attributes and rules would vary from customer to
    customer. We used a variety of strategies such as O/R mapping, Metadata and pluggable interfaces to allow our customers to do this type of customization.

    Our customers have ranged in size from Fortune 100 firms to startups and they varied across a number of industries. In all cases we have been able to deliver on the objective of using our component based framework to rapidly deliver applications in a fraction of the time and cost that it
    takes to deliver solutions with traditional packaged software. Over the past three years our products have evolved to include a rich set of applications that run on these components, and thus closing the gap between a pure
    component solution and traditional packaged software.

    Regards,

    Suneet Shah
    CTO, Diamelle Technologies
    www.diamelle.com
  16. I think that the problem is that there are only few players on the market who could have enough marketing strentgh to "mold" their customers perception of business to fit their component model, that being SAP, IBM and... Well, noone else I guess. These guys seem to feel no need at the moment to undermine their existing enterprise solutions that are still selling pretty much ok, in favor of new solutions based on open interfaced components.
  17. If I remember it correctly, the first version of J2EE specification was finalized at the end 1999 or begining of 2000. J2ee become mature by the end of 2000. At that time the economic situation went down. Corporation spending has been bad for three years.

    There is a market for j2ee components. The demand will be there soon.

    Perfecting J2EE!
  18. Of course, it's always seemed that "GUI components" were more

    > easily understood and appreciated than "business components"

    Maybe they're easier to grok because they are in your face...or very closely related to things that are. In other words it is the terminal (visual) objects that drive the GUI show, and if you're not terminal you need a darn good reason for being around. A business layer is not typically pinned to anything so tangible, and thus we end up in the zoo.
  19. If I remember it correctly, the first version of J2EE specification was

    > finalized at the end 1999 or begining of 2000. J2ee become mature by the end of
    > 2000.

    Really? I thought EJB moved directly from not-ready-for-primetime to outdated. ;-)
  20. I have to agree that you can't simply use business logic across projects that are involved in completely different industries, because the object models don't always play nice together. But I can speak from within my own industry, higher education, there have been great efforts to define standards, and we are starting to see some success. For instance the Open Knowledge Initiative (OKI) at MIT has defined several education specific services, or components if you like. These components attempt to describe the business problems specific to higher education. The idea is that applications across the enterprise can reuse these services. In addition, since these industry specific components are interfaces, ideally this means that applications could be ported from one enterprise (university) to another by simply reworking the implementations. Of course goal has yet to be fully realized.

    So my point is, I don't think its Sun's responsibility to necessary develop industry specific components, that is something each industry needs to work out for itself. Working this out can be a slow and painful process so beware.
  21. Perhaps we need a Java CPAN[ Go to top ]

    In the perl world theres a lot of reuse of modules via CPAN.

    It would be nice if there was a Java equivalent (perhaps there is and I haven't found it...).
  22. Perhaps we need a Java CPAN[ Go to top ]

    Errr,

    You mean libraries here.. I think they are something else that the enterprise components mentioned in the article..

    The last time i checked, the java world wasn't short of any good libraries. The j2se is already full of usefull libraries and look at all the other API's sun et al. are offering.. (jakarta etc.)
  23. Perhaps we need a Java CPAN[ Go to top ]

    \Joost van de Wijgerd\
    You mean libraries here.. I think they are something else that the enterprise components mentioned in the article..
    \Joost van de Wijgerd\

    Language can be a slippery thing. What's the difference between an app server and a component? Struts and a component? Any old library and a component?

    Most of the difference seems to be that components seem to magically live without external dependencies. You plug them into whatever, and they just work. I think cumulative man-millenia of work has shown that truly indepedent components are either too trivial to be worth the while, or pull in their own boatload of internals that offer performance, memory, or integration problems.

        -Mike
  24. Double Edged Sword of Choice[ Go to top ]

    In addition to what others have said, I think there are a few more things that may have contributed to the lack of reusable components.

    1) UI components rule. The vast majority of reusable components on the Microsoft side were (and still are) associated with building user interfaces. Much of this momentum in UI components was built up before the Web took off as a business application platform. Swing, while it continues to improve, has not taken off with the mass of Java developers. This initially had to do with the learning curve associated with using it correctly. Today I think most applications are just written for Web clients, so Swing may have missed out on an opportunity to gain similar momentum (and the UI component market that may have appeared as a result). That brings me to my second point.

    2) No standard Java Web framework. Today we have dozens of choices; one of which being the "roll your own" choice. Struts is certainly the most popular, but I argue that it is not necessarily receptive to reusable components (mainly because it is more of a controller framework). The JSF standard is promising in this respect for two reasons: it is billed as the standard Java Web UI framework (whether or not this happens in reality remains to be seen) and, unlike Struts, it is more receptive to the idea of reusable components (with its pluggable UIComponents, renderers, validators, converters, etc.). Ultimately, when you have one framework in use by the majority of developers (like in the .Net world), you will likely have more resusable components (more demand).

    3) EJBs usually aren't necessary. I do agree to some extent that reusing business components is a very tricky (and usually unprofitable) business, but I think there is something else to consider. EJBs are not necessary for most applications being built, so how can we expect an explosion in reusable components for something that only a minority of applications actually (or should) use? I think we have a double whammy here.

    4) Open source gravy train. I think we are a bit spoiled in the Java world with a relatively high-quality treasure trove of freely available frameworks, tools, app servers, etc. This is certainly where Java has been a stark raving mad success. But as I argued in point 2, too much choice will actually hinder the visible proliferation of reusable components. After all, why would I create a reusable component for a tool, framework, etc. that most Java developers don't use?

    In closing, I think reusable components will be more likely once we have very few popular UI application frameworks that are receptive to such components and once we either have a winner in the IDE space or a common plugin API for the most popular ones (which is actually in the works). In other words, enough demand exists for people to create and maintain these components. Incidentally, the portlet spec is another opportunity to realize reusable UI components (even across different implementations - best of both worlds).

    Enough rambling ... what do you think?
  25. Double Edged Sword of Choice[ Go to top ]

    Couldn't agree more with your excellent summary...

    As somebody who comes from a Windows development background I'd add the following observations on the state of Java components
    * The 'not invented here' syndrome seems to be far more evident in the Java world. There's too much re-invention going on - the Java world needs to standardize on
    * Poor basic spec of GUI frameworks. I'm staggered by how little products like Struts and JSF offers out of the box. I for one can't take any GUI tier seriously that fails to include basic UI compoennts like a grid, scrolling table, and a tree.
  26. Where are all the components?[ Go to top ]

    There are no EJB components if that is what you mean.... I think EJB's are a fraud, relative to anything else out there in software ever. So lets just ignore them for a second.

    I opened up Eclipse, to list out the components I was using, to enumerate what I have used in production over the last few years:

    · Jakarta commons net for NNTP
    · Sf.net informa for RSS
    · Antrl for parsing
    · Cglib for OO
    · Commons beanutils – as the name says
    · Jakarta Commons langs – for strings
    · Jakarta Commons validator – for client side java script validation
    · Sf.net displaytag – for a grid
    · Ibatis for DAO
    · Sf.net Jasperreports – for reporting
    · Itext – used by jasperreports
    · Jdom – for XML
    · Jakarta Jstl tag lib
    · Struts menu – for javascript menus
    · Struts-el, itself, the standard framework

    Etc.

    I can always find a few components for any tasks. Images? Uploads? Hello!?!
    So there are plenty of components out there (and I link them on basicPortal cheat sheet page). More components on the way, like (matt kurses_ javascripttoolbox tag for javascript calendar popup up

    Because of components, java productivity is pretty high. It’s about to get higher, when we (at least I) start to use them as a utility WS.

    I also started using Pico, I think things like Pico (or competing containers) have potential to become a standard component container (simple, compatible)

    .V

    ps: If you can’t find these things, you can download “Jasic” from basicPortal.sf.net, you get integrated IDE (Eclipse) with a JSP 2.0 container Tomcat5/Resin3, a sample app using all above components integrated and tested, plus a stress test tool, and more. It’s just integrated open source comments, and a portal (portal is open source but does also have a commercial license – it competes against Nukes, Zope, Plone, etc.; a cheap but real portal)
  27. SALE NOW ON ![ Go to top ]

    I've got a whole bag full of EJBs I don't need anymore.

    Most of them just read and update a database but they do this with impressive amounts of code and other miscellaneous files. Also they can take up to a week to build and deploy, but I find this gives me more time to browse the net.
      
    I'll swap them for a smelly bit of cheese.
  28. I wonder if "Component" doesn't mean too many things.
    You just can't compare a UI Component, a technical component (like XML parsing) and a Business Component that take charge of business responsabilities like matching clients and products.
    That misunderstanding, that I can find in your posts, is probably one of the reasons for the "business component" market to be very low.
    If we want to sell "Business Components" we need to define what they are, what they offer, how we can customize them....
    I'm still conviced that this market should rise some day. There's not point that for any project you design and build a "customer component", or an "order component"....

    What do you think?
  29. I wonder if "Component" doesn't mean too many things.


    Good point.. there is a previous post that lists "components".... are these really components? What is a component?
  30. I use components a lot[ Go to top ]

    I can't agree with Joseph and I can't agree with the business component comment of Floyd either.
    I am building projects for customers every day and without components it would be hard to realize. First I use a lot of Open Source component from e.g. Apache.org, like Logger component (Log4J), or components of the commons project. The next step is that these components are based on components. Look at the Avalon project of Apache. For me the best introduction and framework for components. Simple and functional. They say services for components now, but it is still the same. A lot of Apache projects are based on Avalon.
    In addition to these more "technical" components I use a lot of business components, too. SAP has a lot of great business components that I can use in Java. Siebel has them, too. And for a user I've used OSUser from the OpenSymphony project.
    My actual customer is an insurance company and there are a lot of companies that are making money only by providing components for partner systems, product systems etc...
    Floyd is right no component will be used in two projects in the same way. But a good component (in my point of view) is customizable, configurable and extendable so that it will fit your needs. (see SAP's approach)
    EJB may be one approach for building components. My personal experience is that a simple approach like Avalon is the best:

    - Have a nice simple interface and separate the implementation
    - Design by contract
    - Inversion of control
    - Define a simple lifecycle

    And my tip: Use Java classloader mechanism more for secure component development.

    Building a big application with a component oriented architecture will save you a lot of pain and time!

    Mirko
    :wq
  31. Mirko -

    I don't think what you are saying goes against what Floyd and others are saying. The notion of (the overloaded word) "components" that hasn't materialized is the notion that when you start an application, you will go out and buy all of the components that you need, and just "put them together" as an application assembler. There were "meant" to be all of these vertical domains where if you want to write an app that has to do with farming, you can buy a whole set of farming components. THAT kind of thing hasn't really happened in the way some wanted (for good reasons as people have mentioned).

    What we DO have available, are many system components that we can use. We have layers to build on (app servers, pico container, etc) which give us code reuse, we have libraries that we use everyday, but we DON'T have a market of lots of business components.

    D
  32. EJB's have succeeded as a client-server technology, but failed as a component technology. I've wondered why, and I can only come up with two reasons:

    1) EJB's capture business logic, which by its nature tends to be at least partially proprietary
    2) Development schedules are invariably so compressed that designing for reuse even in the same company or department is not an option (the best I've seen done is very limited reuse of GUI components, and potentially some DAO)

    Bleeding edge technology seems to result in cut-throat processes. Until this changes we won't see many truly reusable business components. And by that time (if it ever happens) won't the incentive for business component reuse have been pretty much obviated by SOA? ;-)
  33. It doesn't help the "component" side of things when many EJBs are written like you would write a POJO.

    Also, the high level of cohesion (high coupling) required by most applications prevents re-use. The parameter types are often application objects, and no one writes "terminal classes" any more -- everything seems to drag the entire bronx zoo of a class graph with it.

    FWIW, I think EJBs have failed (thus far?) as a reusable component model primarily because they made some simple things into elaborately difficult tasks, and made some things too easy that should never have been done at all.

    Sometimes it's important to look at what works and ... well, copy it. Microsoft did better with VBXs (which were a technical hack and a half) than anyone has done before of after (including Microsoft). We should examine why they were so successful for their time, and try to adopt those traits. Similarly, ActiveX components, Office integration, business components from various application platforms (SAP, BAAN, JDE, etc.) (Of course, it's always seemed that "GUI components" were more easily understood and appreciated than "business components".)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  34. Fantastic dream[ Go to top ]

    D,

    you are right, if we think of component market in the way of just assembling an application - we don't have these components and I think we will never get them. But what we do have is a Business component market where we buy business components and than make some "glue-code" and put some technical components around them like LOG4J for Logging and Tangasol Coherence for Clustering.
    I don't want to invent some CRM features from scratch. I buy some Siebel Components. The same is with accounting etc. I buy some SAP components.
    Just being an assembler is a nice dream but will never be reality...oh wait I remeber a nice presentation...you make some clicks, generate a lot of code and you get a wonderful ready-to-use application with all Gamma and Floys patterns (and more) in only 10% of the time :-) I think the product is called OptimalJ...

    Mirko
    :wq
  35. Where are all the components?[ Go to top ]

    A component must adhere to a specification. The more places that specification applies to, the more reusable the component is. We find that software components tend to apply all over. A ZIP file on my system adheres to the same standard (specification) as a ZIP file on any other system, and so a component that uses ZIP files can be used everywhere. (Even there, opportunities exist for differentiation.) In contrast, business-oriented components are much less standard. Even where the data is (nearly) the same (consider your stereotypical User class/table), the business logic I need for User's is just about guaranteed to be different from the business logic you need.

    Furthermore, even assuming I could use your User class, it's not likely that your interface differs from what I need or expect. So I can't "plug-and-play" your User. This means that there is no way to standardize interaction between components. If I want to use your User class, I also have to adopt your Address, Account, LineItem, SalesOrder... and by the time I've integrated all your classes, I might as well have written my own.

    In summary, the combination of varying business specifications for common candidates for components, plus the lack of standard specifications for interfaces, combine to make it difficult to create components that are applicable across a diverse spectrum.

    -Thomas
  36. Simple Components Please[ Go to top ]

    I don't see that true component reuse is addressed anywhere in the J2EE spec to this point. The focus that J2EE has had historically centers around EJB. And EJB is primarly a way to abstract databases.

    J2EE has really become a kitchen sink of APIs and specs. It is a way for big software vendors to sell you very very expensive software. While the major vendors offer things like hardware clustering, load balancing and reliability type features in their products, notice most of these concepts are outside the scope of J2EE.

    I would rather have my software folks be very good database and sql developers than invest in a bloated and expensive J2EE implementation. One can achieve the same quality and reliability with a solid database and a good appserver/servlet tier than with any J2EE/EJB platform.

    Unless you have a rlatively simple Pet store type application you will be locked into the J2EE vendor.

    Unless one day you can buy your SAP Component/EJBs off the shelf then all you are getting with J2EE is a guideline for building software. And a guideline is fine for the less complex stuff.

    Java is a great language and platform for building server-side software but the current direction things are going I don't see it addressing component reuse.

    To address this, what I think is needed is a very simple way to define what a unit of server-side work/code is without all the bells and whistles. No EJBs or JMS....etc. Here is my server-side code and I want it run in this container. It should have the option of exposing properties and reading inputs and working in a secure/unsecure sandbox. These components can be connected togther by someone (not necessarly the person that wrote them) using simple mapping logic or point and click. A component developer should have no new APIs to learn beyond what is in the J2SE.

    Here is a concept I have been exploring:
    Check out http://jobbean.sourceforge.net/

    -Sam Taha
  37. An opening for an EJB component alternative?[ Go to top ]

    There have been a lot of good points made on the question, but Sam's post suggests another, related question. Do you think there's even any opening for a "proprietary" container for plain Java classes? Would it have to be open source, or is there even a commercial opportunity? There seem to be a number of emerging lightweight containers (Pico, Nano, Spring, plus Avalon of course and JBoss AOP microkernel in some ways falls into this category): do you think they will eventually take market/mind share from EJB? I've developed one of these containers and am trying to figure out if there is a place or demand for it. One problem in the component market--which a few people have highlighted--is that people tend to hew to de jure (JCP) or de facto (say, Struts) standards, many of which are limited as platforms for reusability, and avoid "non-standard" competitors.
  38. People have been using various frameworks that smell an awful lot like a "container" for literally decades now. Long before Java, in industries like financial services companies would build tremendous architectures built entirely upon their own services, frameworks, libraries, and containers. To this day, the more advanced Java projects I've seen invariably have their own enclosing framework which is either home-grown, or built on some external product.

    The various lightweight containers we're seeing today are really, to some extent, homegrown frameworks being brought out to a larger audience. When I worked at Bear Stearns (seemingly eons ago), alot of code ran inside of standard containers, which were really home-grown middleware. And that was pretty common, because the developers recognized a need to standardize at the runtime level (beyond library/framework reuse), even if it was only within a company.

    The difference is that the industry has caught up, to some extent, and companies don't have to build so much infrastructure themselves. In regards to light-weight containers, I've seen many companies aggressively take them in, because they were a bit more widely known, or because they did a similar job as internal jobs, only better. And for open source projects, because the source is always there. For a small company or individual directly maintaining someone else's open source tree in house may seem daunting, but for a big IT department that spends, say, $500 million a year, it's not such a big deal. Worst case scenario, the open source project goes dead, or branches off in some wild direction not suitable for the company, and they go on maintaining the branch themselves in-house. From their perspective, they're still better off than doing it all in-house.

    And of course, in alot of big industries, "standard" is not the number one criteria. It's important, but not even in the big three. The big three are "it's fast, it's reliable, and it does what we need". "Standard" is nice, but not if none of the implementations work, or are slow, or are unreliable. Or if the standard itself kinda sucks for your needs. A brokerage on Wall Street will go for standard if that's what works, to reap the benefits of using a standard, but they'll ruthlessly use whatever works, even if non-standard, if no standard offering is available, or measures up to the non-standard approach.

    Looked at from that perspective, going with something like Nano doesn't have as big of a risk as you may believe. Hell, there was one brokerage on Wall Street that actually invented their own programming language at one point in time.

    Standards are good, but they are not Gods that you should follow over the cliff to your own destruction. Look for standards that work for you, and if you don't find any, then either go outside the standard for products that do accomplish what you need, or by god build something yourself.

        -Mike
  39. Because of the database ...duh[ Go to top ]

    An enterprise component needs to talk to a database. Entity beans don't work for all the apparent reasons, so I won't rehash that here. What is needed for enterprise components to take off is a clean deploy-time linkage between the component and the database.

    The component needs to be able to negotiate storage requirements with the container as part of the deployment. When JDO has a standard OR mapping schema, this will become viable.

    Secondly components don't work in the "just string 'em together" manner that sun envisioned. Anyone hiring an "Application Assembler" lately? Didn't think so. The reason for this is because the EJB component interface breaks the OO model. In order to have an API simple enough to string components together, yet sophisticated enough to be useful, you need full blown OO. That's why it's easy for us to integrate frameworks into our standard java applications, but so relatively difficult to incorporate EJB "components" in an enterprise design.

    This is one of the reasons I think enterprise applications are going to benefit from JDO. You can present your enterprise API in terms of POJO objects. The "component" simply becomes a deploy-time bundling like a WAR file. In terms of integrating these "components" in your server-side app, its no different than writing a standard java app.
  40. Because of the database ...duh[ Go to top ]


    > Secondly components don't work in the "just string 'em together" manner that sun envisioned. Anyone hiring an "Application Assembler" lately? Didn't think so.

    It's important to distinguish between components, as a concept with many different potential implementations, and EJB, one particular (very heavy and arguably flawed) implementation.

    > The reason for this is because the EJB component interface breaks the OO model. In order to have an API simple enough to string components together, yet sophisticated enough to be useful, you need full blown OO. That's why it's easy for us to integrate frameworks into our standard java applications, but so relatively difficult to incorporate EJB "components" in an enterprise design.
    >

    It's also why you see a lot of opensource libraries, many with ties to Servlets or other API specs, but few (none?) based on EJB.

    > This is one of the reasons I think enterprise applications are going to benefit from JDO. You can present your enterprise API in terms of POJO objects. The "component" simply becomes a deploy-time bundling like a WAR file. In terms of integrating these "components" in your server-side app, its no different than writing a standard java app.
    >

    Why should I use JDO when I can use Hibernate and have it actually work NOW?
  41. Because of the database ...duh[ Go to top ]

    <snip>
    The reason for this is because the EJB component interface breaks the OO model. In order to have an API simple enough to string components together, yet sophisticated enough to be useful, you need full blown OO
    </snip>

    Do you? I doubt that very much - but of course JDO is a cool framework. I rather think that full blown OO is much of an obstacle of componentization rather than an enabler. As long as most software developers still fail to understand what polymorphism is the solution is probably to go for a more simple model.
  42. A large number of issues[ Go to top ]

    I am an academic as well as developer, and one of my research areas is Component technology (as part of the Swinburne Unviversity Component Research Group). There a large number of issues raised so far in this discussion that are entire areas of research.

    Firstly definitions. A component in the more academic sense is a piece 'black-box' software with a clearly defined interface. So Corba and COM with IDL and EJB with Remote/Local/Home interfaces all fit this bill, as well as various other pieces of technology. Libraries like Log4J, Jakarata-Commons etc would generally be considered as 'frameworks'. As mentioned by Mike (I think) earlier, language is very slippery, and so these are not 'hard' categories and the lines blur pretty badly at the edges.

    One of the major issues with component reuse, which is in essence what we are talking about, is that even though we have interfaces, these interfaces basically define method signatures, but leave out but leave out a huge amount of information that is necessary for a component to be successfully integrated into a system, including quality, security, interactions and dependencies.

    I think one of the reasons for the undeniable success of the Open Source Java libraries is that having access to the source (and very granular source ... for example Log4J is quite a small library) means that developers can get a real feel for how the integration of the library will effect the system. Also, most of this stuff tends to be quite low-level, as was observed earlier.

    I also think that a major issue with the idea of 'Business Components' is that pretty much everything at the business level is about data and about interacting with a datastore. This is what business software is all about (and this is also why TheServerSide will degenerate into wild discussions whenever EntityBeans/JDO/Hiberate/JDBC/etc/etc are mentioned). This means that any Business Component will have an IMMENSE dependency - the database itself. Without a way of specifying this kind of interaction at the compoenent level, the notion of third-party components is a big issue.

    As I write this I do have the thought that EJB could solve some of this stuff. Entity Beans allow for the abstraction of datastore issues, and Session facades provide a clearly defined 'service' layer. It would be possible to distribute third party EJB components and handle the database dependency with reasonable efficiency. The main issue would then be customisation, of course. How do you get the precise 'Customer' component you need - every business will have different requirements and it becomes untenable very rapidly. I don't think that there is really a technical limitation at this level, much rather a pure business issue.
  43. A large number of issues[ Go to top ]

    As I write this I do have the thought that EJB could solve some of this stuff. Entity Beans allow for the abstraction of datastore issues, and Session facades provide a clearly defined 'service' layer. It would be possible to distribute third party EJB components and handle the database dependency with reasonable efficiency. The main issue would then be customisation, of course. How do you get the precise 'Customer' component you need - every business will have different requirements and it becomes untenable very rapidly. I don't think that there is really a technical limitation at this level, much rather a pure business issue.

    >

    This is why it's important to have a persistence framework which allows OO development, including inheritance.