JBoss to Apply for Official J2EE Certification

Jonboy X writes "CNet has an article detailing the resolution of a long-standing feud between open-source J2EE server vendor JBoss and Sun. It seems they've decided to break down and shell out the clams to be certified by Sun. Quoth Bob Bickel, JBoss's vice president of corporate development and strategy: 'Our core base of developers, a lot of them say they don't give a damn...But the reality is that a lot of big companies who are using this are moving into production.' JBoss gives away its server software and survives on support contracts."

Comments

JBoss

[Anonymous Coward]

Can someone please explain to me, concretely, what exactly JBoss is, without using the term "business logic"? I've even used it and don't understand what it is.

Re:JBoss

[baywulf]

Quite simply, JBoss is a Java application suite that allows for vertical integration of enterprise databases using back-end query protocols thus providing for scalability and reliability within the IT infrastructure. Ah fuck-it I am too lazy to generate this meaningless technobabble.

Re:JBoss

[eakerin]

It's simple Jboss is an open source implementation of the J2EE Specification.

Done, without using "business logic".

Of course, you're no further along than when I started.

So What's J2EE you ask, Well That's where it gets more complex. J2EE is a large thing, but it basically runs down to this.

1. Have Client code that knows how to display the data (Either a webpage or a client application, etc)
2. Have a middle tier system that provides the ability to do things (basically it's a bunch of methods and objects that a client can use, no matter the client) This is where the work is done, like calculations, rules like "You have to have a PO on file in recieving before you can have something shipped here", and other things. That way you can change the rules and calculations without having to update the client, and so all clients use the same rules and calculations. - JBoss does this job.
3. A backend Data Store, (Normally an RDBMS) this stores data for the Middle Tier to use.

Basically it provides for sepirating Presentation, Logic, and Data (come on, I said logic, not "business logic", it's close enough right?)

4. Profit - wait how'd that get in there?

Re:JBoss

[AJWM]

Basically it provides for sepirating Presentation, Logic, and Data

Or in other words, Model (Data), View (Presentation) and Controller (Logic). (Although arguably in the MVC pattern the model can also include some logic, just not view-related logic. Think of triggers and constraints in the RDBMS.) Either way, separation of these is generally a Good Thing.

Re:JBoss

[Anonymous Coward]

Zzzzzz, zzzzzzz, chchchch, zzzzzz...

Re:JBoss

[Anonymous Coward]

Why does MVC have to show up every time people talk about Java applications? J2EE is not MVC. MVC is not J2EE.

MVC is a design model for applications. J2EE is a platform. Two different things.

Re:JBoss

[karlanka]

So what's the difference between this an traditiona DB-stored procedures? To me it sound like a B-version of stored-procedures.

Re:JBoss

[los furtive]

So what's the difference between this an traditiona DB-stored procedures?

Stored procs are tied to the database, and some would consider this a violation of MVC. Ideally a well implemented business logic separate from the DB will allow you to change databases with minimal code rewrite.

Re:JBoss

[karlanka]

Yes but that's just a theory. All databases are far to different to allow that.

Re:JBoss

[karlanka]

Don't see the difference here. J2EE is tied to JAVA which is tied to SUN.

Re:JBoss

[eakerin]

I'm of the opinion that you should keep your Data layout logic in stored procs, that way, it's just a matter of updating a few procs if you need to change table layout, and it further sepirates logic from the data model, plus pre-compiled query plans can help out a lot for performance on complex queries.

Of course IAADBA (I am A Database Administrator) so my opinion may be skewed.

Re:JBoss

[rimu guy]

JBoss let's you run JSP pages and servlets. Of course, Tomcat and Jetty offer that as well.

JBoss offers things like EJB, JMS, JNDI, transaction management, clustering, container managed persistence and DB connection pooling.

Whether you need those things or not, is another question. Whether you use those things to create model-view-controller designs is also another question. You can write an J2EE app and it can still rank up there with the worst code designs in history.

One quite cool things about J2EE (and servlets) is the ability to create web application files (.war or .ear). You just assemble this file then pop it on the server. Voila. No further configuration required. It just works.

Another reason a lot of people use JBoss is because it (or rather, J2EE) looks really good on your resume. You can become buzzword compliant by simply downloading the app and having a quick play on a Sunday after noon. Ooops, got to kick that facetiousness habit.

Anyway, I'm glad that the JBoss group thinks it's worth shelling out $100K pa on certification. Provided they get their payback from the corporates that want the certification, not us regular joes that just like JBoss because it works.

- RimuGuy
JBoss Hosting on Linux VPSs

Re:JBoss

[Anonymous Coward]

I find it really depends on how you're using the database. Arguably most database applications are heavy on the "read" side, light on the "write" side. Furthermore, most database applications are interested in "localized" data. In other words, they mostly read, and when they write, the effect of the write is limited in scope.

Occasionally, however, the database application needs to perform a lot of writes. If, in addition, the data is highly inter-related, such that writes are not "localized", then the overall picture changes drastically.
For example, let's say your data represents a graph of dependencies, and you need to perform traversal-based calculations that frequently update (write) the data: then your "logic" needs to be embedded in the database (as stored procedures perhaps), rather than in the "middle tier" code, as the "middle tier" is just too slow for such large amounts of data.

In sum: it's fine to embed the application logic in the middle tier "business logic" code, assuming that your "business logic" can perform its decisions based on user input, pre-defined rules, and possibly some small amount of data. HOWEVER, if your "business logic" needs to access a lot of data just in order to perform the decisions, then this "logic" needs to be embedded directly in the database for scalability purposes. At that point, your "middle tier" becomes more of a "data adapter" / "user input processing" layer.

Thoughts?

Re:JBoss

[timjdot]

The questions I've seen are:
1) What does the staff know (db guys do stored procs not Java code)
2) Are there other app.s hitting the data? Maybe then the stored proc.s are a central location for business logic.
3) How fast is the db/ does the app need to be? No matter what db vendors claim, running queries will never be as fast as in-memory objects; even ignoring that the db server is often across a wire. This can be ignored for simple app.s but once the data is over a few thousand records in a few tables and the logic is complex then you really do have to move some data into memory rather than hit the db every time. Consider an algorithm that must touch every row and its relation to another table: better to "cache" the data in memory.
4) Where is the "official data"? Is it in the database? Is it in memory? Both? Is some in one database and some in another? Should the JSP developer's have to contend with knowing this? Etc.
5) Your point that if the algorithm is update intensive then putting it in a stored proc makes more sense.
My experience,
TimJowers

woohooo!

[larry bagina]

this is great news! Too bad i don't care.

What is J2EE 101

[Phouk]

JBoss is a "J2EE container". J2EE, "Java 2 Enterprise Edition", is an "industry standard" and technology by Sun to help writing the back-end part of high-end server software. You can write software ("components") according to certain specifications, and then run that software within any server that conforms to the J2EE specification, of which there are many (JBoss, IBM WebSphere, Bea Weblogic ........).

J2EE is quite different from the kind of Java that runs on your desktop (so-called J2SE - Java 2 Standard Edition) in that it contains a huge set of additional libraries and specifications, both for those writing the J2EE container, and for those writing the software components. This way, both sides - container and components - can make strong assumptions about each other. Because of this, and since the component is running "inside" the container, the container can provide a lot of services (read: "magically available features") to the components, much more easily than if the component writer had to call and coordinate several libraries.

These features include:

• clustering and failover
• transactions that span more than one database, or include systems other than databases (so you can't just use database transactions)
• a standard way to connect to mainframes and ERP software (JCA)
• saving your objects to database tables, including cluster-safe caching
• connecting to secure message queues
• interfacing with directory services (ldap, active directory etc.)
• etc. etc.

If you really need more than one of the above, maybe you should take a closer look at J2EE. If not, don't bother - J2EE is very large, and takes a considerable effort to learn well.

If you don't understand what this is worth..

[immanis]

If you don't understand what this is worth, you really haven't had to try and fight with people in the company who have the power to say "No, we will not use JBoss in production."

People are pushing hard for JBoss. The answer, from the people who have the power to say no, has always been "It's not proven."

Those people NEED things like official certifications to believe in products. They need it more than a list of who is using it where. And they will pay millions of dollars for a product that gives them these assurances..

Re:If you don't understand what this is worth..

[sporty]

Problem with jboss is, it tries to be too complete a soltuion. Thinks like, it's implementation of JAAS. What if I want my user to know what the particular reason for a failed login is? You have to use an extra threat to yoink the informatoin out since the interface doesn't allow you to pull it in a clean manner.

I'm wondering how resin is doing in this field...

Re:If you don't understand what this is worth..

[Anonymous Coward]

It's sad really - comes down to abdication of responsibility. The "IT Operations Management" people are completely unwilling to take on personal responsibility for their systems anymore, operating under the delusion that a commercial vendor means someone to sue, thus absolving them of any sin if the system breaks down. In practice, of course, you can;t sue the vendor. I've been a company that has tried. You'll find out two things. (a) EULAs do have legal teeth. (b) Your operations people will be found negligent and ruin your case if they even once say "the system just crashed, it must be the vendor's fault", if they haven't gone to absurd lengths with debuggers and profilers.

All in all, you're better off with Open Source - there, your operations people HAVE NO LAME EXCUSES.

Re:When are Java developers going to wake up?

[NeoBeans]

IBM's participation in JavaONE probably reflects an attempt to curtail spending at trade shows that won't increase their bottom line.

If you look at IBM's involvement in the Java Community Process for J2SE and J2EE you'll see there are over 20 IBM-led efforts under the umbrella of a process that is managed by Sun.

Sun may not have product to capitalize on Java, but as a steward of the standard, the company is still in a uniquely powerful position.

seems a bit late to me..

[mannionh]

Its seems strange that the JBoss Group has decided to seek J2EE certification at this stage when JBoss appears to move further from the J2EE spec with each release. They even clearly are aiming to market themselves themselves as "Beyond J2EE", according to their site.

Want It, Need It...

[sipy]

Not only do I rejoice that JBoss will obtain J2EE certification (you don't doubt it, if they're shelling out the $$, do you?), I *need* them to obtain it.

The single reason that my company gave to me for not using JBoss, and, instead, settling on the expensive, monolithic, do-it-this-way-or-be-damned "application server" from WebLogic was... "JBoss is not J2EE certified."

I would have given my right nut to have been able to say "oh, yes they are!"

We're still dealing with rollout/stability/cost/upgrade-track issues that came along with the "priviledge" of paying tens-of-thousands of dollars for something that is absolutely free. Heck, we could have afforded to hire a brand spankin' new programmer JUST to keep an eye on these servers, had we used JBoss, and saved the money for licenses, upgrades, down-time, over-time (etc).

I just don't get it... all this press about open-source, not to mention rapant capitalism/downsizing/squeezing every penny out of everything, and yet the dolts in the corner offices still act all stupid, shelling out megabucks for some marketing-driven, bug-laden piece of crap software - when all the while, high-quality, *actually usable* software is there for the taking for zip, zero, nada. I just don't get it...