SCWCD or SCBCD ?

[Cesar Perez]

I am SCJP for 1.4 and Im preparing for the upgrade exam which I should pass without problems, I hope and I was wondering which one I should take first as I am more a backend developer than front end.

So what do you think? Web or Business?

Thanks

[Vassili Vladimir]

Do you work ?

If yes, what do you do at work ?

Work on web technologies or business logic tier ?

That depends !

If you do core java, then go for SCJD ...

Regards,

[Cesar Perez]

Yes I work and I usually do more business logic although I have also worked with JSP, JSF and a little bit of Struts. My last project was more business logic and UI but we used Flex instead which I love BTW.

[Vassili Vladimir]

mmmmm,

What about both

Do both man!

Since you have experience in both, then do both.

You can start with SCWCD since it has a book.

After completing your SCWCD, you can go for SCBCD!!!

What do you say ?

[Cesar Perez]

Which one should I take first? well after I do my SCJP upgrade exam.

[Paul Michael]

Most people (if I got my statistics right) take WCD first before BCD.

It was also the same path that I took. But like what they said, it will mainly depend on what YOU would want to focus more on.

By the way, I'm also currently using Flex and loving it.

Have you ever considered taking the Flex Developer exam also?

[Nishal Dsouza]

Hi

Since You are working in web technoloies. Better to take scwcd first then go for scbcd. Even i was planinig to take scbcd first. Later i changed my mind and took scwcd.

[Arjan Times]

Originally posted by Paul Michael:
Most people (if I got my statistics right) take WCD first before BCD.

I'm considering taken them the other way around for a very specific reason: SCWCD is seriously outdated, while SCBCD is very up to date. Where I work, we're mainly using JSF and Facelets. Although the Servlet part of SCWCD is still interesting, I feel weird training for a J2EE 1.4 set of technologies, while we are completely based on Java EE 5. Don't forget that J2EE 1.4 is from 2002. There have been some changes in the world during the past 6 years, but the material in SCWCD hasn't changed at all to reflect this. Basically you're learning nearly 6 year old stuff.

My hope is that while I study for SCBCD, Sun will introduce a new exam that focuses on the Java EE 5 web layer, instead of the one from J2EE 1.4. There have been a few hints here and there that something like this may happen, although sadly nothing really substantial.

[Charles Lyons]

SCWCD is seriously outdated... Don't forget that J2EE 1.4 is from 2002. There have been some changes in the world during the past 6 years, but the material in SCWCD hasn't changed at all to reflect this.

Except for JSF becoming a core part of the spec, what changes would those be? Do you mean the minor things like whitespace trimming in JSPs? Or perhaps EL 2.1 - the new features of which only really work within JSF?

I think the reason most people take SCWCD in preference to SCBCD is there is higher demand in the workplace for Web developers and much less demand for EJB developers - to run an EJB server properly you need better infrastructure than to run just, say, a Tomcat container. This is why the vast majority of hosting companies who offer Java Web hosting only offer the Web tier (and even that's only a thin slice of those offering Web hosting at all).

It is also true that while you do logic with EJBs, you can do everything from logic to presentation within the Web tier (yes, it won't do things like CMP for you, but if it's only a simple model it doesn't really matter and you can code the support up for yourself or use an existing framework).

EJBs have also frequently been referred to as a "bloated" API, though with the new annotations this is much less of a truism. Indeed, I've been using EJB CMP (persistence) in my latest Web project by deploying under Resin... works a treat and means I don't have to code database updates from my beans! But I never took the SCBCD...
[ May 10, 2008: Message edited by: Charles Lyons ]

[Arjan Times]

Originally posted by Charles Lyons:
Except for JSF becoming a core part of the spec, what changes would those be? Do you mean the minor things like whitespace trimming in JSPs? Or perhaps EL 2.1 - the new features of which only really work within JSF?

I mainly refer to JSF itself. Several exam authors, including Bert, have already mentioned that JSF is too large to fit in to the SCWCD exam and that a separate exam would be a possibility.

The thing is that pure JSP programming does not happen a lot any more. At least not in the projects I was or am involved with. I'm a big fan of learning the fundamentals of the technology I or my teammates use though. SCWCD only partially fulfills that. The Servlet API and web.xml are still very relevant, but much of JSP and JSTL really isn't. Of course, that's just for me personally, although I feel it's also not very relevant anymore for a lot of other people.

As I already mentioned in several posts, I was also put off by the fact that SCWCD 5 is about J2EE 1.4. There's not a -single- Java EE 5 thing in there. The exam already was about a 6 years old programming paradigm, but it also actually is about a 6 years old spec. The least they could have done is update the exam to JSP 2.1 and Servlet 2.5. Some keep stressing that the changes in those specs were too small to warrant inclusion in the updated exam, but if they were so small you could just as well say that there's no reason to explicitly exclude them from the exam.

to run an EJB server properly you need better infrastructure than to run just, say, a Tomcat container.

This is another discussion really, but I think that kind of comment very much represents a ~2002 way of thinking. During that time Java application servers were big commercial things with a hefty price tag and complicated support contracts. Tomcat could just be downloaded and it worked. Fast forward to 2008. A full Java EE implementation can be downloaded just as fast as one can download Tomcat. They are free, they are open source and they install just as simple. Most people I know add at least JSF, JPA and JTA and often JMS separately to Tomcat. If you add all that, you suffer quite some overhead of keeping a ton of individual jars up to date. It's far easier to start with a full implementation (Jboss, Glassfish, Geronimo) and remove what you don't need, then to start with a minimal implementation (Tomcat, Jetty) and add stuff from different locations, with unknown dependencies and varying release schedules.

At least Jboss very easily lets you disable stuff you don't need, and Glassfish lazily loads parts of the Java EE API that your app is actually using.

This is why the vast majority of hosting companies who offer Java Web hosting only offer the Web tier

The kind of people who make use of shared hosting rarely do a lot more than building some simple web pages.

It is also true that while you do logic with EJBs, you can do everything from logic to presentation within the Web tier

You can, but as your application grows you really shouldn't. It's perfectly ok for small web sites to do everything in the web tier, but the larger your app gets, the more you'll be fighting against spaghetti code creeping up everywhere. At some point in time you simply *need* MVC, where the M in there is based on a solid foundation of a DAO approach with services and transactions.

I'm not advocating that every small web site should be MVC, but when you need it, you need it. No point in arguing with that. Not every building is a high-rise, but if you do need a high-rise you better have some architecture to support it.

(yes, it won't do things like CMP for you, but if it's only a simple model it doesn't really matter and you can code the support up for yourself or use an existing framework).

I'm not sure I follow. We have JPA these days and it works really well. It's a simple XML or annotations (you choose) based model. It can be used in a Java SE application, or in a container managed environment. The latter gives you the benefit of simple declarative transactions among others. Of course, if you really wanted you could also use JPA directly as a scriptlet on a JSP page.

JPA is on the SCBCD exam...

EJBs have also frequently been referred to as a "bloated" API, though with the new annotations this is much less of a truism.

Much less? It's a complete anti statement with EJB3. Many people find EJB3 to be lighter than say Spring (which arguably isn't that light actually, but still) and with something like OpenEJB3 you can even unit test your enterprise beans outside the application server.

[Charles Lyons]

I agree with most of your points, except:

I mainly refer to JSF itself. Several exam authors, including Bert, have already mentioned that JSF is too large to fit in to the SCWCD exam and that a separate exam would be a possibility.

Okay, but surely the SCWCD would be a prerequisite to JSF? You should understand all the basic components (which JSF relies upon) before using JSF, so you'd end up taking the SCWCD anyway. Of course, that opens a whole can of worms too - there are many developers who prefer other frameworks (like Struts) over JSF, or whose employers force them to adopt alternative frameworks, so that exam just wouldn't be relevant to them at all.

The least they could have done is update the exam to JSP 2.1 and Servlet 2.5. Some keep stressing that the changes in those specs were too small to warrant inclusion in the updated exam...

They're not just too small, but they're also very gritty details which are of little relevance to most developers. As far as I can tell, the authors of the new specs went "hey, we've got a great platform here which does everything we want, so let's just make a few minor changes and call it a new spec - that way we keep in line with the rest of Java EE 5 where the changes are really in the EJBs".

Just skimming the specs now, the only changes are:

JSP 2.1:

Related to JSF - itself and EL 2.1's deferred expressions

JspApplicationContext to support EL 2.1

TagAttributeInfo now has getter for description of attribute

J2EE tag libraries load first

Generics in the APIs

JspId tag handler IDs

Trimming whitespace and using byte order marks in JSPs

Servlet 2.5 (MR5)

Annotations and resource injection

Minimum J2SE requirement

Allow any HTTP method name in authorization

Allow multiple occurrences of servlet and filter mappings

web.xml required

ServletContext.getContextPath() added

With the exception of annotations/injection, these are tiny changes. Looking at servlet 3.0 however, we're again moving towards annotations to replace web.xml just as in EJB. An example from the spec:

@Servlet(urlMappings={"/foo", "/bar"})
public class SampleUsingAnnotationAttributes {
  @GET
  public void handleGet(HttpServletRequest req, HttpServletResponse res) {
    // ...
  }
}

will replace the need for <servlet> and <servlet-mapping>s in the web.xml - so you don't need one at all! Now that's an advancement I would hope to see in a new version of SCWCD in a few years time...

Fast forward to 2008. A full Java EE implementation can be downloaded just as fast as one can download Tomcat... The kind of people who make use of shared hosting rarely do a lot more than building some simple web pages...

My point was not in downloading/installing on a home machine, but the system requirements on a server to run. Tomcat is fairly lightweight, there are some hosting companies (using private JVMs or even VPSs - not JVM shared hosting) which support Tomcat, but relatively few who run, say, JBoss or Glassfish due to higher RAM requirements. There are developers who want to showcase their ideas to the client (you can find their blogs if you Google) but don't have their own datacentre or servers so are looking to show them off on a monthly rental basis - it's just hard at the moment to find EJB hosting. This will probably change, but it is a factor in ease of deployment for smaller companies or the individual.

[Arjan Times]

Originally posted by Charles Lyons:
Okay, but surely the SCWCD would be a prerequisite to JSF? You should understand all the basic components (which JSF relies upon) before using JSF, so you'd end up taking the SCWCD anyway.

It would be great if the exam was indeed positioned that way, but somehow I feel it isn't. The concepts of a Servlet and a Filter are indeed good to know before starting with JSF. JSP is already less relevant, although it's still the default view technology for JSF. A slight alignment of the terminology (e.g. the term "action" is never used for custom tags in JSF) and some focus on 'bridging' concepts (e.g. the unified EL) would do miracles.

But maybe it's just me being too picky about puzzle pieces fitting together

As far as I can tell, the authors of the new specs went "hey, we've got a great platform here which does everything we want, so let's just make a few minor changes and call it a new spec - that way we keep in line with the rest of Java EE 5 where the changes are really in the EJBs".

I agree with you completely. The thing is, if the authors of the new specs went that way, why couldn't the authors of the exam do the same?

It are indeed only small additions. Perhaps they wouldn't justify creating an entire new exam for, but if you are creating a new exam anyway, why leave these out? It's a minor detail, but there are now indeed generics in the APIs, yet students have to learn explicitly that supposedly Java EE 5 does not have generics in those APIs. We constantly have to remind students that SCWCD 5 is not about Java EE 5, but about J2EE 1.4, even though the exam was released long after Java EE 5 was released. I just fail to see the logic in there.

Plus, inclusion of the unified EL instead of the JSP 2.0 EL and the annotations + resource injections would form a perfect bridge to a possible JSF follow-up exam. As you probably know, the unified EL is identical to what you use in JSF (hence the name ) and the annotations + resource injections for a Servlet are identical to what you use in JSF managed beans.

My point was not in downloading/installing on a home machine, but the system requirements on a server to run.

Ok, I hear you. I have always worked for companies that had their own servers, so for me this never was a problem really. Also, on my own machine I don't see a lot of difference in resource consumption between plain Tomcat (with added libraries) and Jboss or Glassfish. I guess you're right that in a shared hosting environment where every byte matters the advantage for Tomcat is still there.