Win a copy of Java EE 8 High Performance this week in the Java/Jakarta EE forum!

Ajith Kallambella

+ Follow
since Mar 17, 2000
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ajith Kallambella

Lots of good answers and I have to agree with all of them.

The bottom line is, SCEA is a technology architect certification that attests that the candidat knows how to use Java/J2EE technology to solve a business problem. Recognize here that the breadth of the problem("the assignment") is no where comparable to real life situations, and the approach( that you solve your assignment alone sipping coffee in Starbucks) no where applicable in real life. When you become an architect for real, you typically deal with more complex problems, and the need to apply non-technical skills to implement a solution. That makes the applicabilty of SCEA rather limited. And the cerficiation will not make you an architect. Trust me.

That said, SCEA is a great experience. Just going through the process of self validation and getting your solution assessed by Sun( er, Oracle ) in and of it self is a worthwhile endeavor. It might even help you stand out from a stack of resumes and earn an interview. But once you land a job( if you do) as an architect, your success will depend on not how you got there, but what you need to do there to stay competitive. Understanding the business, selling your value proposition, strategic thinking, leadership, and most importantly, contribution to the bottom line ( $$$ ) are the skills you have to develop to succeed as an architect.

Components are usually higher level entities in your solution design and therefore, may be implemented using a bunch of classes. UML allows stereotyping, and I strongly recommend you to use stereotypes to add more clarity to your component diagram.

Back to your question, you can use the lollipop notation to depict interfaces exposed by a component. Remember that a component fulfills a functionality by exposing a set of behavior( via interfaces - not necessarily Java interfaces, but think of a "contract ). The best way to model a component is to include its interface descriptions. If you show all relevant interfaces in the component diagram, then you could use the same interface in the Class diagram to suggest the linkage. This is one way to do it.

Other way would be to use package notations. You can show what packages are in which component, and then use the same package name( as a stereotype ) in your class diagram. You can also get a bit more creative by using color codes( for example, all classes in a particular component are painted Yellow ).

I hope that helps.
Why? Why are you in such a predicament ? If you need to access a private variable outside the class, you have to think about your class design.

Having that said, you can use Spring to do this.
7 years ago
I would include significant operations that represent the behavior of the class. I have seen many people struggle with this idea of how much detail to show in a class diagram. In my opinion, classes without operations are not terribly useful, because operations are how behavior is implemented. At the least, you should show the operations that are used in the sequence diagram.
I'll take a shot at it.

how do you see the future of enterprise architecture compared to implementation roles, design roles and assembling roles (

Enterprise architecture is more about the 'big picture' - aligning business and IT. The 'EA' in SCEA is about J2EE's applicability across the enterprise, and not about the "enterprise architecture" it self. The role of Enteprise Architect will be above the application architect, and more akin to CIO/CTO. This is where one would deal with a more abtract representation of the architecture, and seek business value.

Are there alternatives to SCEA for example is there a Microsoft Software Architect exam and how is it compared to SCEA?
You answered your own question in some sense. SCEA is about architecting enteprise solutions using Java language and J2EE platform. It certifies your competence and your ability to understand different tools offered by the J2EE platform and apply them wisely, judiciously and aptly. MCA, although from Microsfot, is surprisingly not about any Microsoft technology. It quizzes you on some qualities every architect is expected to demonstrate, including abstract thinking and communication. I personally have come to value MCA a bit higher than SCEA because of the broad scope included in the certification criteria.
[ March 25, 2008: Message edited by: Ajith Kallambella ]
Good deal! Congratulations Dinesh.
Why can't you make the following assumptions

  • Checkout results in only one of the two states - paid or unpaid shopping cart.
  • A paid shopping cart means all items are paid.
  • Once the shopping cart is paid for, items cannot be modified.
  • Modifying items is only allowed for an unpaid shopping cart.

  • Moving this thread to Java in General forum.
    10 years ago
    Pay attention folks. This still holds water. I'm going to get trigger happy for some time. If your post is missing, it means I spotted something unacceptable.

    Do not ask for real questions. Posts of this type will simply be deleted!

    Study Hard and Good Luck!

    The assignment as well as the other two parts of the test is considered confidential. It is fairly well detailed out so you don't have to worry about the ambiguities. I encourage you to read through old posts in this forum and even by just grazing, you'll find enough information about the assignment. In military terms it is called Passive intelligence gathering

    Good luck!
    [ May 29, 2007: Message edited by: Ajith Kallambella ]
    It sure feels nice to be missed

    Your observations are correct. That I haven't been around as much as I'd like, and as much as most of you would like, and that I'm not usually needed outside situations that require serious policing.

    On a personal note, I have been swamped with my studies. For those of you who don't know this, I'm pursuing my second Masters degree at Carnegie Mellon. With job, school, and a toddler at home I'm not left with much time to do things I really like doing.

    I'll try to be around as much as I can. In the meantime, if you really, really, really need my attention, drop me a note at
    This happens all the time, more often than you think. Just pick two jar files from your server class path and see how many classes they have in common.

    A class loader will only load the class once, from the first "resource" it can find that has the class. So it is never a problem until as Ande points out, two different class loaders load potentially different versions of the class. When versions conflict, usually you get an error that hints that serialization identifier of the classfile is different than the one expected.
    11 years ago
    You have two options

  • Use XSLT transformation and custom style sheets to consume your XML file at build time and churn out Java classes.
  • Use some kind of byte code injection( like ASM ) and custom Classloaders to create Java classes on the fly.
  • Have a hybrid option - generate the entities that are static at build time using XSLT and the dynamic behavior at runtime that uses bytecode generation.

  • How much of runtime dynamics do you want to support? The build time option above is certainly simpler than the byte code injection option however, if your XML file changes then you need to rebuild the app.
    11 years ago
    This topic appears to be broader than just preparing for SCEA. I'm moving this over to EJB/J2EE forum for the benefit of a larger audience.