SCBCD still relevant and worthwhile?

[Kram Nart]

Does pursuing the SCBCD still make sense if Sun gets bought out by another company such as IBM? How true is the comment about the JavaBeans folks getting fired from Sun? What's your thought on this?

https://coderanch.com/t/436529/Meaningless-Drivel/IBM-talks-buy-Sun-Microsystems

[Hong Anderson]

Rational was acquired by IBM long time ago, even today they still support RUP.

[Reza Rahman]

Kram,

I would take all of this with a grain of salt. It is still mostly rumors. The SCBD is as relevant as it always has been.

Regards,
Reza

[Joe San]

Kram Nart wrote:Does pursuing the SCBCD still make sense if Sun gets bought out by another company such as IBM? How true is the comment about the JavaBeans folks getting fired from Sun? What's your thought on this?

https://coderanch.com/t/436529/Meaningless-Drivel/IBM-talks-buy-Sun-Microsystems

What has Javabeans or SCBCD got to do with it?

[Kram Nart]

Jothi Shankar Kumar wrote:

Kram Nart wrote:Does pursuing the SCBCD still make sense if Sun gets bought out by another company such as IBM? How true is the comment about the JavaBeans folks getting fired from Sun? What's your thought on this?

https://coderanch.com/t/436529/Meaningless-Drivel/IBM-talks-buy-Sun-Microsystems

What has Javabeans or SCBCD got to do with it?

Well, because I'm in the process of studying for the SCBCD and I'm looking for some positive indication that it will be relevant for at least a little while. The SCBCD is a Sun product after all, and who knows what its next reincarnation might look like after some other company takes over. I just want to put my time, energy, and money towards something worth all of those things.

[Reza Rahman]

Kram,

The point is that the SCBD is unlikely to change (the same is also true of Java/Java EE as a whole) with or without Sun. Also, as I said, I don't see the wisdom in dwelling too much on something that is a rather distant possibility and more or less looks like a media hoax at this point.

Best regards,
Reza

PS: I think a Sun merger with a more stable company is inevitable and a good thing. I am not sure IBM would be the most developer/community friendly choice, though. I was personally hoping for Apple or Red Hat with the hardware part going to some other company like Fujitsu or HP perhaps.

[Kram Nart]

Reza Rahman wrote:Kram,

The point is that the SCBD is unlikely to change (the same is also true of Java/Java EE as a whole) with or without Sun. Also, as I said, I don't see the wisdom in dwelling too much on something that is a rather distant possibility and more or less looks like a media hoax at this point.

Best regards,
Reza

PS: I think a Sun merger with a more stable company is inevitable and a good thing. I am not sure IBM would be the most developer/community friendly choice, though. I was personally hoping for Apple or Red Hat with the hardware part going to some other company like Fujitsu or HP perhaps.

I agree with you Reza, that Java is not going away anytime soon. It's just that there's a valid point from the buyout thread I've posted, and that is, something might be around (like COBOL) but it may not be relevant. Personally, I'm sold on Java. Perhaps Oracle would be another company that would make sense in shaking hands with Sun as well, if that will ever happen.

[Reza Rahman]

Kram,

Yet again, the point is that it would be just as relevant. A Sun merger/sell-off, should it indeed happen at some point, is really a non-issue as to Java, Java EE or the SCBD in the long and short run. The only thing that would make it "less relevant" is a serious alternative to any of these and none are really all that obvious. Anyone that compares Java to anything like COBOL is seriously out of touch with reality or is attempting to evangelize alternatives that have yet to be proven viable in the long run.

Hope it helps,
Reza

[Hong Anderson]

I agreed with Reza, what will happen if Sun was acquired by other company is not related to Java, Java EE, it's different issue.

[Kram Nart]

Thanks for the confirmations. I got kind of spooked by that whole discussion about things losing popularity and eventually phased out in that thread.

[Hong Anderson]

Even Sun is not acquired by other company, it doesn't guarantee that EJB 3 will be popular, Spring Framework can compete with EJB 3 in almost every aspect.

[Kram Nart]

Kengkaj Sathianpantarit wrote:Even Sun is not acquired by other company, it doesn't guarantee that EJB 3 will be popular, Spring Framework can compete with EJB 3 in almost every aspect.

You're absolutely right. This article mentioned briefly about that and what it might mean for Java in general http://www.eweek.com/c/a/Application-Development/Java-Developers-Leery-of-IBMSun-Merger-411968/?kc=EWWHNEMNL03262009STR1.

[Reza Rahman]

Kengkaj Sathianpantarit wrote:Even Sun is not acquired by other company, it doesn't guarantee that EJB 3 will be popular, Spring Framework can compete with EJB 3 in almost every aspect.

I don't think it's that black and white, guys.

For example, I hear from a lot of folks these days that are looking into EJB 3/Java EE 5 now that SpringSource is looking more and more like a traditional software vendor. I was at the TSSJS conference where Rod made these blatantly anti-Java EE comments. My Spring/EJB 3 integration talk is what had the highest interest levels amongst attendees in surveys and the session attendance level/participation was very good. The book sales for EJB 3 in Action has been steady and rising for quite a while now.

In terms of EJB 3 adoption, the biggest issue seems to be who has upgraded to a Java EE 5 server. Whomever is doing that is also investigating EJB 3 as their primary business component model.

I think Java EE 6 will maintain this direction, especially with DI in JSR 299 (JCDI). For example, JCDI is a lot cleaner, more annotation-driven and has features that Spring does not.

Cheers,
Reza

[Hong Anderson]

Reza Rahman wrote:
For example, I hear from a lot of folks these days that are looking into EJB 3/Java EE 5 now that SpringSource is looking more and more like a traditional software vendor.

I couldn't disagree .

IMO, the biggest problem of EJB 3 adoption is the fact that many people don't have good feeling about EJB 2. EJB 2 is quite famous in bad things, like complexity, performance. Although, EJB 3 is much simpler than EJB 2.x, but EJB name has been already dragged in mud.

I think maybe it would be better if Sun change the name, like from EJB to SEB - Simple Enterprise Beans, but I think that would be impossible.

I don't like some concepts of EJB, it's too heavyweight, for example, default TransactionManagement is Container, and default TransactionAttribute is Required. Hm, is it true that EVERY business method (or most of) requires transaction?

About thread-safety feature that leads to instance pooling feature (EJB container MUST provide instance pooling feature because enterprise beans are thread-safe), is it true that EVERY business method (or most of) should be thread-safe?

[Reza Rahman]

Kengkaj,

I agree on the perception issue. We are attempting to do something similar to SEB in JCDI (JSR 299). Personally, a renaming for marketing purposes seems silly. I think educating people is the more correct option. After all, we are talking about engineers, not the general public buying food, clothes, etc:-).

As to container managed transactions, thread-safety and pooling, my personal experience is that it is the simplest and most robust choice for business components. I actually think Spring has it wrong in this regards and a Spring business tier winds up directly or indirectly looking exactly like EJB with more configuration complexity on the way (e.g. did you know Spring implements thread-safety under the hood too?).

Cheers,
Reza

[Hong Anderson]

Reza Rahman wrote:(e.g. did you know Spring implements thread-safety under the hood too?).

If you mean Spring's data access template classes, yes, they are thread-safety. But as I know, general Spring managed beans are not thread-safety.

For me, we should do only what is needed, it's no use in using thread-safety for services that don't need it.
It might be easy to make every bean thread-safety, but easy things are not always the right things .

[Reza Rahman]

Kengkaj,

Kengkaj Sathianpantarit wrote:It might be easy to make every bean thread-safety, but easy things are not always the right things .

Note, in my experience, 95% of business components access/manipulate resources such as databases and network connections that need to be thread safe. As a result, making business components thread safe *is the right choice*. The other way round is simply the wrong design since it does not fit the majority case (which is why the Spring APIs end up implementing thread-safety under the hood anyways). Also, it is a little bit of a frivolous argument, but Spring DAO support classes and APIs *are* Spring beans. The only difference is that they implement thread-safety via custom code instead of an inherent service of the component model itself.

Think about it this way -- some people drive convertibles. This doesn't mean that every car should be designed with the front wind-shield only and add side windows and the top frame as an option. In reality, most of us prefer the safety of a fully covered vehicle, so that is what makes sense for the "default" car design :-).

Best regards,
Reza

[Hong Anderson]

Reza,

Reza Rahman wrote:
Note, in my experience, 95% of business components access/manipulate resources such as databases and network connections that need to be thread safe.

Hm, from my experience, it's not that much . And, I'm not sure how do you count.
For example, if we have a service interface which has 10 methods, each method call data access services (thread-safety). Are these 10 methods counted as things that need to be thread-safety, I don't think so, because only data access services are required to be thread-safety.

And in domain layer, there are many services that don't access/manipulate resources, those services don't need to be thread-safety.
However, this depends on how we design the domain layer, and characteristics of the domain.

About thread-safety, I found a comment from Rod Johnson:

Generally there are no thread safety issues in the service layer. For example, look at typical SLSBs: they are given pooling by the container, but in reality don't need it, as a typical SLSB has no read-write instance variables after it's configured.

In the rare cases where you strike something that isn't naturally threadsafe in the service layer, you can use synchronization. Or you can use Spring's own pooling capability (see the AOP chapter in the Reference Manual).

http://forum.springframework.org/showthread.php?t=12434

If I misunderstand anything about thread-safety things, please let me know.

[Reza Rahman]

Kengkaj,

The issue here is that I disagree with Rod's assertion because it does not match reality for most service methods that I see. In fact, in typical Spring-ish fashion it is rather self-serving and devoid from real reasoning if favor of authoritative doctrine :-). Often such assertions fall apart on closer inspection :-).

Most service methods that I see *do* end up either reading or writing data (both operations need to be thread-safe, not just the read operation). This is especially true of web applications where most requests that result in a database interaction (think of the typical banking or e-commerce application, for example). I agree domain objects do not need to be transactional or thread-safe. However, in Java EE, JPA entities are domain objects, not EJBs. EJBs are either the service facade or the DAO, both of which need to be thread-safe and transactional.

To state it another way, anything that is transactional really needs to be thread-safe too because it implies usage of a shared resource (otherwise, why bother with a transaction at all). And even in hard-core domain-driven design lingo, services are supposed to be "thin transactional scripts". This follows that most service operations do need to be thread-safe.

If you have concrete evidence otherwise, I sure would like to see a realistic example that represents a majority of real life enterprise applications :-). Honestly, I am a little surprised that the Sun architecture test doesn't cover this! Shame on Sun!!

As to your argument about only data access APIs needing to be thread-safe, other than the Spring data access classes, neither a JDBC, JPA, Hibernate, TopLink or iBATIS "session API" is thread-safe. The reason for this is performance. This is precisely why you are effectively forced to use the Spring specific data access classes in a Spring application. The other choice is having verbose resource factory handling code everywhere data access is necessary.

Cheers,
Reza

P.S.: As much as this discussion is valuable and interesting, I think it might be a little off-topic for this forum at this point. If you want to continue, perhaps it is best to move into a a more appropriate spot such as the EJB forum or the "meaningless drivel" forum?

[Krishna Srinivasan]

Yes..it will be worth if you are taking the EJB 3.0 certification.

[Hong Anderson]

Reza,

Reza Rahman wrote:Kengkaj,

The issue here is that I disagree with Rod's assertion because it does not match reality for most service methods that I see. In fact, in typical Spring-ish fashion it is rather self-serving and devoid from real reasoning if favor of authoritative doctrine :-). Often such assertions fall apart on closer inspection :-).

I think most services are as Rod said, except data access services.

Reza Rahman wrote:
Most service methods that I see *do* end up either reading or writing data (both operations need to be thread-safe, not just the read operation).

I think we shouldn't talk about *end up*, for example Service A call an operation of a data access service. Data access service must be thread-safe, but is it necessary for Service A to be thread-safe as well?

Reza Rahman wrote:
To state it another way, anything that is transactional really needs to be thread-safe too because it implies usage of a shared resource (otherwise, why bother with a transaction at all).

Agreed.

Reza Rahman wrote:
And even in hard-core domain-driven design lingo, services are supposed to be "thin transactional scripts". This follows that most service operations do need to be thread-safe.

Did Evans said that? Could you please give me a link? In DDD, I couldn't recall that Services are supposed to be "thin transactional scripts", although I'm not sure what does "thin" in this context mean.

Reza Rahman wrote:
If you have concrete evidence otherwise, I sure would like to see a realistic example that represents a majority of real life enterprise applications :-). Honestly, I am a little surprised that the Sun architecture test doesn't cover this! Shame on Sun!!

I agree that SCEA should cover this topic, it's important.
About example, maybe it's not a majority of enterprise applications, but you might get the idea.
Let's say we have the following services:

Calculate Hash Value from a model (Or calculate/compute anything from parameters)

Export model to file/Read from file to model

Check validity of model for example by using Specifications

For me these services don't need to be thread-safe.

Reza Rahman wrote:
As to your argument about only data access APIs needing to be thread-safe, other than the Spring data access classes, neither a JDBC, JPA, Hibernate, TopLink or iBATIS "session API" is thread-safe. The reason for this is performance. This is precisely why you are effectively forced to use the Spring specific data access classes in a Spring application. The other choice is having verbose resource factory handling code everywhere data access is necessary.

Yes, that is what has to be done, without using or developing a framework we will have a lot of boilerplate code, fortunately Spring offers template classes that guarantee thread-safety.

Reza Rahman wrote:
P.S.: As much as this discussion is valuable and interesting, I think it might be a little off-topic for this forum at this point. If you want to continue, perhaps it is best to move into a a more appropriate spot such as the EJB forum or the "meaningless drivel" forum?

I would be appreciated to hear your opinions and suggestions. You may move this topic to EJB forum.

[Reza Rahman]

Kengkaj,

Here are some things to consider vis-a-vis your questions/comments:

* There is no guarantee that there always need be a separate data access tier that is made thread-safe somehow. As I mentioned, none of the popular data access APIs are thread-safe for performance reasons. In fact, some people have argued that JPA makes the DAO layer obsolete: http://www.infoq.com/news/2007/09/jpa-dao. In this scenario, you could be using JPA directly in your service tier. This means that the sensible default component model for any serious enterprise application with decent quality of service should be thread-safe, as EJB is. The nasty alternative is that developers can make threading mistakes, have to hand-write threading code or make sure every API they use is thread-safe - not a good choice in my opinion. This goes back to the default commodity car design analogy I made. Spring dangerously makes you unaware of these issues by making their particular data access APIs thread-safe in an underhanded manner that most people don't realize.

* Data access is not necessarily the only thing that needs to be thread-safe. For example, logger APIs that use I/O streams (to output to log files) or socket connections (to write to a centralized/distributed log manager) need to be used in a thread-safe context as well. That's just a small example. Thread-safety issues in a DI system can occur in many other ways. Take a look here for a good discussion: http://weblogs.java.net/blog/tomwhite/archive/2006/09/are_your_beans_1.html. The only reason most Spring applications don't get into big trouble because of this is the fact that mid-sized applications do not use many shared resources beyond data access and because like the Spring data access APIs, the most commonly used logger, log4j, is fully thread-safe (and hence can cause deadlocks/performance problems, but that's another story that I don't even want to get started on).

* As to the questions around service/domain logic/transactions, please review the role of the service tier (what Eric Evans calls the "application tier") in a domain driven design application and how it fits with domain objects. I hate quoting things (feels so academic as opposed to professional), but here is Eric Evans says:

"The application Layer [Eric's name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program."

Here is another good resource that clarifies some of this: http://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/. As you can see, the primary responsibilities for this tier includes coordination between domain objects, providing transactional boundaries, defining an atomic unit of work meaningful to the application, providing security, etc. Because of this role, the service layer is often characterized as a "thin transaction script used to coordinate domain objects". This is the layer that EJB 3 components excel in.

* I think we've come to the reasonable conclusion that a vast majority of operations in the service tier of a web application do perform data access, correct? Or are you still claiming otherwise? If you are not, hopefully it is clear why being thread-safe and transactional by default makes sense for the service tier?

* There is no need for the data access tier to have any boilerplate code. The point is that the container should do all the boilerplate things for you automatically. After all, that's exactly what the container managed JPA entity manager does in a Java EE 5 system, correct?

The part that scares me is that folks like you who have gone through the Sun certification process for the architecture track are still unclear about these issues. I think that's a communication failure on part of Sun and perhaps the other Java EE vendors such as JBoss. They seem to be perfectly content letting SpringSource make whatever misleading assertions they choose to make to naive developers!

Hope it helps,
Reza

[Hong Anderson]

Many thanks for a valuable reply, Reza.

Reza Rahman wrote:
* As to the questions around service/domain logic/transactions, please review the role of the service tier (what Eric Evans calls the "application tier") in a domain driven design application and how it fits with domain objects. I hate quoting things (feels so academic as opposed to professional), but here is Eric Evans says:

"The application Layer [Eric's name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program."

Here is another good resource that clarifies some of this: http://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/. As you can see, the primary responsibilities for this tier includes coordination between domain objects, providing transactional boundaries, defining an atomic unit of work meaningful to the application, providing security, etc. Because of this role, the service layer is often characterized as a "thin transaction script used to coordinate domain objects". This is the layer that EJB 3 components excel in.

I think we have different understanding about "Services". When I say "Services", I'm not talking about Application Layer, but I'm talking about a model element pattern named "Services" of the three patterns Entities, Value Objects, and Services. Services are in *Domain Layer*, they express domain functionality and operations.

We are also able to have services that don't contain domain functionality which should be in Application Layer.
For clarification, I think we can user terms like Application Services and Domain Services.

[Reza Rahman]

Kengkaj,

Understood. That is the terminology Eric Evans uses. However, as far as I know, he is pretty much the only one. Most folks mean the "application" layer when they talk about "services". Certainly most people doing SOA/Java EE use it in that sense...

Hope it helps,
Reza

[Hong Anderson]

Yes, most people don't know and don't use Domain-Driven Design (Domain-Driven Design is like Design Patterns in a sense that some folks may have used it, but call it differently).

At least, Eric Evans is not alone, I'm a big fan of Domain-Driven Design .
And as I know, in my country, I'm not the only one who uses Domain-Driven Design .

[Reza Rahman]

Kengkaj,

Just to be clear, I have nothing against DDD. In fact, I have written a few DDD systems myself. However, I do not believe DDD is an end all be all/cure all. Like more traditional architectures, it has its pros and cons, I believe.

Best regards,
Reza

[Hong Anderson]

Regarding the acquisition rumor, I don't like it, but the rumor was true: I.B.M. Reportedly Will Buy Rival Sun for $7 Billion.

[Reza Rahman]

I know this has a serious impact on us, but I would treat it the way it really is - just still a possibility. There is nothing final here yet. It needs to be passed by Sun as well as green lighted by the regulatory bodies in the U.S. and Europe. Neither is a slam dunk.

For one, I know most Sun employees are not terribly excited over this.

Cheers,
Reza

[Amol Katyare]

Quite interesting thread

First of all, Thanks Reza for giving us EJB3 in Action - such a wonderful book. I really hope, more and more people go through it so that they would get familiar with the simplicity of EJB 3 over EJB 2.1. The book has been written with very simplified contents, flow is very good (esp. for beginners). Giving ample code snipptes with pointers to highlight important lines is really a good way to grab attention of readers. The same example of "ActionBazzar" carried out through out the book glues you to book. You can't wait to get familiar with newly added features (esp. annotations) and how they are used to serve your requirement.

However, it would be great to enhance "Best Practises" section and have more practical problems/solutions into it. I think one can list down the problems that developers usually face and what should be done to avoid it. E.g. I see many people have posted when they see problem with dealing with detached entities, getting JPA excpetion at persistence level. configuration questions regarding persistence.xml etc. Also, confusion between how to use JPA in EE and SE context. etc.

Coming back to original discussion topic of this thread...

Well, IBM + SUN deal may have lost it's balance but Oracle did it (Great anticipation by Kram Nart ).

What would be your views on the future of Java (and hence future of Sun certification exams) after reading this ?