Win a copy of Rust Web Development this week in the Other Languages forum!

jono

Greenhorn
+ Follow
since Dec 22, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by jono

Stanley,

that looks like one of those ambiguous whizlabs questions! I found whizlabs very good for improving my score and focussing in on the right areas but I felt some of the questions were very ambiguous and some were actually wrong. However, for the record - these are the reasons for using EJBs that I adhere to:
------------------------------------------------------------------------
EJBs should be used when you need either security or transaction support. Outside of this you need to question why you are using EJBs.
EJB Provides
- Transaction Management
- State Management
- Resouce Pooling
- Security Checks
- Number of pooled instances specified at deployment time.

Specifally in relation to the mock question you posed - I agree with the Sheriff. It depends on what is going on t the backend as to whether security or transactionality is required. The question does not give enough detail to decide this and thus you cannot determine whether you shoudl use EJB or not. Furthermore, even if security and transactionality is not an issue, J2EE best practices sugest that in a complex system, employing an MVC archiecture and maintaining business services in EJBs exposed through Business Services Facades is stilla good idea. etc.. etc.. the more I think abtou it, the less useful this question gets!

hope this helps
hi,

Unfortunately I do not think this group can answer this question as it is a design decision which you must make for yourself. I woudl say the following though: There is rarely just one right solution so provided yours makes sense - go with it!

sorry I can't help more
Hi,

I used the package element and a <<subsystem>> stereotype

works fine. you coudl sue the subsystem element in Rational Rose but depending ont he reader they might not consider it valid UMl so I stuck with the package
Vu,

this one coudl do your head in

either solution seems valid. just make a choice and stick with it. if you look at different airline companies they provide flights and search fcilities in different ways and with different levels of success. So there is no correct functional answer. Just state how you are doign it and make sure your logic is sound. It doesn't have to be the perfect functional solution, just the perfect technical solution!
Lucy,

I never figured that out. And I didn't worry about it either. I took the information contained therein and incorporated it where possible but I didn't try and figure it out.
Hi

As lucy said........

The factory method allows you to abstract the creation of an object from it's implementation. You provide a defined interface method but the implementation is in a different class which can vary depending on requirments.

The point of an abstract factory is that once you select the factory, all product you create through that factory will be from a single "family set" - you can't accidetnally create one class from one group and one class from another
Hi Lucy,

In theory there is no problem with using the one BD & SL for a Java Client & Web Client. I would prefer to use two versions. It allows you to change their implementations separately - this is particluarly relevant if the rates of change of the two clients will vary greatly. You coudl have them inherit from the same base classes.

I am not sure why the use of EJB 1.1 is relevant? Any remote client will have to use remote interfaces to talk to Business Services deployed in an EJB container - this woudl be the case in EJB 2.0 also?

best of luck
Hi,

When drawing a sequence diagram tp represent a Use Case you need to have a sequence diagram for each Use Case... This woudl indicate you need to perform the alternate flows but you can put them on different diagrams
Hi

There is no hard an fast rule about what shoudl go on the Component diagram. The instructions are (I think) to include all the J2EE components. I also included "pattern" components i.e. POJOs which represented patterns e.g. Service Locator. The idea is to show your logical J2EE component architecture. How does your system function logically? What is the flow through the system, how do the components interact and where are they logically located.

hope this helps
Hi,

Not sure how you have a composite entity bean in the class diagram? The DOM shoudl show the entities involved. A composite entity bean woudl appear in a Component Diagram.

The Class Diagram (DOM) shoudl be an extension of the BDOM. Or to put it another way, a representation of the BDOM in the software world.

The Component digram shows J2EE components. There is not necessarily a 1-to-1 relationship between entity beans and domain objects.
Hi,

There are two books whch aim to cover everythng:

Mark Cade's "Enterprise Architect for J2EE Technology - Study Guide" which is best used as a reference for Part 2.

Another recent on that I can't remember the name of. sorry....

The 4 books I used were:
Mastering EJB - Ed Roman
UML Distilled - Martin Fowler
Design Patterns - Gamma et al.
Sun's Designing Entperise Applications book - free online

just remeber that it tests EJB v1.1 not v.2.0. I actually just studied v2.0 and got a grip on the key differences during sample exams. no point in leanring the old version just for the sake of it!


regards
[ April 19, 2005: Message edited by: jono ]
Hi,

The whole point of entity beans is that they should be considered the actual "entity view" i.e. it is better to forget there is a database behind the beans. So I woudl not represent anything behind the entity bean. Also, the database itself really only needs to go into the deployment digram as an execution node or a subsystem since it is not a J2EE component or any kind of software component.

does this clarify it?
hi,

thanks for the congrats! I sat part 3 on March 10th and received notice of scores on April 18th - it took quite a while.

1. do u have changed BDM
I did change the BDOM. It is not essential, it depends on your assumptions. Other people here have said it doesn't matter so much what your solution is so long as you can back it up with assumptions. They are testing your knowledge of the J2EE platform and architecture primarily. I cannot stress how important it is to follow this advice - it saves so much time trying to resolve unresolvable conflicts in the requirments.

*2. Flights , segment, seat how u relate this and ur assumptions
about all this.
I will not explain exactly how I did this as it will just be another view added to the variety expressed here., Suffice to say that my view was different than many others I have seen on JavaRanch. They all passed and so did I. Again I say that you just need to clarify the requirments in your own head and back it up with assumptions. The solution itself is secondary to following a valid train of thought. I reckon there are at least 5 or 6 ways you could tackle this. Try not to over-complicate the solution.

3. did u saved unpaid itinerary ?
Yes.

4. how u showed ur component diagram all in 1 diagram.
My component diagram had about 30 components - J2EE components as request and some POJO's indicating key J2EE pattern classes. I left out some TO's since they cluttered things up and explained it in the notes.

5. how many classes and component you had ?
About 30 components and about 16 classes. I was worried my BDOM was a little small relative to others I had seen. It was my weakest score...

Hope this helps. Good luck!
Hi guys,

I have been a relatively quiet member of this forum for some time now. I have tried to pitch in where possible but have felt I didn't have the information to contribute too much. I received my final marks from Sun today and am now a qualified SCEA. Thanks very much to everyone for their help. I will try to help now that I know my input is accurate!!
---------------------------
This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.
Class Diagram (44 maximum) .......................... 41
Component Diagram (44 maximum) ...................... 44
Sequence/Colloboration Diagrams (12 maximum) ........ 11
---------------------------