Kartik Shah

Thank you for the detail answer.

I have few of questions for the authors

What are the benefits provided by Griffon over just using regular Groovy SwingBuilder?

What is the roadmap for Griffon and can you comment on pace of its development?

When do you think we will have GORM type functionality ported to to Griffon?

Thanks in advance!

Thanks and Regards,
Kartik Shah
Blog: http://blog.kartikshah.info

Happy Birthday !!!

POJO = Plain old Java Object. POJO WikiPedia (To my knowledge, the term came into use to describe objects which does not extend any specific technology or frameworks. e.g. EJBs are not POJO because it they extend from EJB interfaces.)

DTO = POJO with Data Transfer Object Pattern applied to it.

See the difference Here

Let me clarify.

DTOshould not possess any logic in it.

The reason to use lightweight DTO is because you are going to use it across the layers. (From your web layer to middle layer to backend layer). This object will be travel as method params or return params. May get serialized.

About your example above, I would still consider it a setter method. Not knowing what is inside setState method, I assume it is only setting the state to concluded.

However, there is certain logic is required to be performed while you change the state (set certain member variables) you may end up including that in POJO.
Like
setName(String str){ if(str != null && otherComplexBooleanCondition) { this.name = str; } }

I would want to emphasis that
Not all Application Server supports JEE

JBoss EJB3 is separate from JBoss Application Server. It is Emebeddable EJB3.0 Container.

Adopting EJB3 will also mean adopting Java 5.0

I would say untill we see more participation, EJB3 is not yet ready for Prime Time.

In terms of Layered approach you will follow
Facade --> DAO --> POJO for populating POJO.

I would like to bring up couple of points:
Every Class should have only one responsibility.
Facade should have only one responsibility which is to act as single entry point to the application services.
DAO should have responsibility to access DB and populate POJO
POJO have only responsibility of representing data in object world.

It wouldnt make sense to include static method in POJO. I agree with scott's remark that then it wouldnt be POJO. Also it will violate principle of Single Responsibility. (i.e. one object should have only one reason to change or change in object should not cascade changes in other objects)

As for your question of reducing dependency Facade should depend on DAO (via interface)

POJO does not represent any behavior. (No logic in it, just member variables and getter/setter). In my opinion, you have to reduce dependency in terms of reducing dependency on behavior. Since POJO does not have any behavior, it is fine. In my opinion, you reduce dependency because you want to reduce cascading changes in classes due to change in one class. POJO does not represent any behavior. Vice Versa, Since it is required that POJO is accessed through all layers of application it is important that it should not have any behavior.

Hello ,

I passed SCDJWS exam today with 88%.

Thanks everybody in the forum.

Here are the resources
1. J2EE Web Service by RMH
2. Blueprints
3. MZ's Webservice Guide
4. MZ's Quiz
5. Other Material for JAXB(tutorial) and Security(Sun Audiocast by rima patel)

MZ's guide and quiz are absolutely fantastic !! Consolidated guide and question in quiz has helped me a lot. Thanks Mikalai.

Thanks and Regards,

Hello ,

I passed SCDJWS exam today with 88%.

Thanks everybody in the forum.

Here are the resources
1. J2EE Web Service by RMH
2. Blueprints
3. MZ's Webservice Guide
4. MZ's Quiz
5. Other Material for JAXB(tutorial) and Security(Sun Audiocast by rima patel)

MZ's guide and quiz are absolutely fantastic !! Consolidated guide and question in quiz has helped me a lot. Thanks Mikalai.

Thanks and Regards,

Thanks for your reply

Sun's Web Service Quiz Page
has following question.

UDDI is a registry and a repository
A. True, because it also allows business documents like schemas and WSDL to be stored in it
B. False, because the the actual content is never stored in UDDI.

It says correct answer is B.

However, in section 3.6.1
Java Web Service Blueprint says

Keep in mind that the public registry holds the Web service description, which consists not only of the service's WSDL description but also any XML schemas referenced by the service description.

But further in section 3.6.2
Java Web Services Blueprint Section 3.6.2it says

Public registries are not repositories.

Help me sort this out ?
[ December 01, 2004: Message edited by: Kartik Shah ]

Thanks Nick,

I found the sample chapter from
J2EE Security Chapter 11: Web Service Security

I think this chapter along with Blue print and Java WS Tutorial should be enough for Security Objectives.

Regards,

Security Chapter from Web Services Blue print
Java WS Tutorial
http://java.boot.by/wsd-guide/ch08.html
http://java.sun.com/developer/onlineTraining/webcasts/singapore/rsrinivas/rsrinivas.html
Web Services Security Book by Mark O'Neill

Please add to list

I am actively preparing for the exam.

Currently, I am going to RMH Books and Blue prints.
Next steps are
[1]Go thru other material which covers objectives not covered in the book.
[2]Cover exam specific material from some of the sites mentioned in forum
[3]Give mock exams.
[4]schedule and give test.

Tentative dates: November end -- Mid December

Regards,

I am going thru RMH book. My Opinion
-- Book is organized pretty well in parts ( and mostly as per sections in objective list). In addition to that RMH has done a nice job in organizing information within chapters.
-- Content of informative and to the point. ( Some books just repeats the same thing again and again which makes it bulkier) The way I see the book, it presents the 1. rule and/or theory 2. example and 3. explaination of example in light of theory/rule.
-- I usually read specification which are complicated ( sometimes !!) After reading intial chapter in RMH book (SOAP, WSDL, UDDI), I read WS-I Basic Profile specification. Reading the RMH book before made it so easy to understand and co-relate rules/restriction defined in WS-I BP. May be much to do with marking of rule with superscript BP.
-- Simple language.