Win a copy of Spring Boot in Practice this week in the Spring forum!

Rumen Krastev

Greenhorn
+ Follow
since Dec 22, 2008
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 Rumen Krastev

http://www.amazon.com/Oracle-Certified-Master-Enterprise-Architect/dp/1430250011

Publisher: Apress; 1 edition (January 15, 2014)

That's what I'd call ambitious... or misleading
Perhaps if Mr. Komar is reading our famous forum would like to elaborate a bit how he thinks to achieve this?

Heilien Tsui wrote:Hi all

I am working on assignment Big Smoke Cigar Shop

Any one can explain to me that any differences between the roles of Freight Movers and International Shipping ?

they seem to be the same role, both accept shipping request, just using different technology.

thanks



What difference do you expect - these are just two shipping providers, keep in mind that use case states the customer may choose between two and than calculate total, means they have different shipping cost ;-) Consider DHL and UPS, they ship to different countries and charge you different fees, the same for FM and IS. Of course they appear as single role as you can see from use case diagram, it's clear and simple.

J J Wright wrote:

I agree completely, when we add Business Delegate and Session Facade, we've the complete picture.



Why do you need a Business Delegate with POJO EJBs?


Correct me if I''m wrong, but Business Delegate helps the presentation tier to decouple from the interface (usually session facade) in business layer, doesn't matter what technology is used in business tier (POJO or not). That means Session Facade and Business Delegate are like twins but stays in the opposite tiers. See the picture in http://www.corej2eepatterns.com/Patterns2ndEd/ and will understand what I mean (even Business Delegate and Service Locator are in purple, which is strange for me).

J J Wright wrote:Where does your product catalog come from?


Not only this - almost all information in modern web sites is dynamic, therefore configuration/customization is an essential feature leading to logical decision to store this data in DB, but I should admit that he is right that nowhere has been mentioned this in use cases, neither system requirements, so in sake of theory I think he could provide design without DB and still pass the test. It even might be explicitly mentioned in assumption section.

Komandir Kozlov wrote:Hi Rumen,

Thanks for your reply. But both your examples seem not very convincing for me. User accounting? Why do you think we should implement it even if we haven't been requested to? There are a lot of e-commerce sites which allow you to make full buying cycle without logging in. Moreover, I am sure that accounting is such functionality which couldn't be missed by our business analyst if was required. Regarding second example, it seems to me questionable to save shopping cart between sessions even with accounting. Most real-life ecommerces don't do this. Again, you are trying to mind up new use case - Shopping cart saving, but we wasn't required to do this!!!

I understand your point, but with the same success we can mind up many more use cases, which wasn't required. Where is the border line???


It's up to you where you'd put the border line, that's why there is assumptions section, hence if you decide no DB, it won't be mistake, but this might open questions about reliability (check about ACID) IMHO.
Just to mention, the shopping process in real life is asynchronous and long-time consuming, definitely longer than a single web session. Think about sending mail with receipt, confirmation mail, report mail for shipping progress, promotion emails, credit card fraud detection, etc. Often the exact payment processing is taking more than one day for fraud prevention reasons and so on and so on. All of these actions suggest storing user info in permanent way. Anyway, these things are not in the requirements and as I said it's completely up to what way you'd choose. I designed my architecture with DB because the system won't be reliable enough if doesn't store transaction, user and order information.

mimi mang wrote:Good points! What I want to do is web tier will use Service Locator to locate the service provided by business tier. As for business tier itself, I prefer to use DI as long as it is available. But seems only those session beans and MDBs can use it. For example, if I use EAO/DAO pattern, I have to get the JPA entity manager by ServiceLocator. Otherwide I have to rely on the caller to pass in it to EAO because EAO is a POJO unless you use session bean as the EAO.


I agree completely, when we add Business Delegate and Session Facade, we've the complete picture.

mimi mang wrote:ServiceLocator is still useful for those POJO objects that are not managed objects for example Business Objects, DAO/EAOs etc. Even in web tier, I don't prefer to use Dependency Injection with annotation. because it can't logically seperate ejbs from web tier managed beans especially when you need 2 kind of presentation tier such as web client and swing client.

The problem is it really make the diagram messy. not sure if we need draw every dependency line to it...



I agree, this pattern could be still useful in some special cases, but DI is essential new feature in EJB3 and behind the scene it's doing much more than just lookup (think about @PersistentContext) like CMT and CMP, therefore I always would recommend using it. About the clear separation of concerns, you can still wrap the injection in more decoupled way if you prefer, but let's remember that annotations came in JEE5 to solve some very typical issue - the bunch of boilerplate code. I would say ServiceLocator is one good example for that and when you see the new DI (JSR-299) is even further improved in JEE6, you'll see that new style of design.
About the pattern existence in class diagram, yes it could become more complex, but it might me necessary since you also would include it in sequence diagram and component diagram to show how exactly your design provide good maintainability and extensibility

Komandir Kozlov wrote:Guys, who are working on this assignment or already has finished it and all others. After reading requirements ten times I still don't see any need for use of DB here from provided use cases. Is it possible? I mean that application will be kind of 'not production' w/o DB, but anyway as I understand we need only to complete supplied requirements and not to try to imagine other scenarios. I understand that we can point this in list of assumptions bla bla bla, but still need your view on this.

To make clear that I am not asking for concrete advice for implementation (which is of course prohibited), I just wondering if it is possible at all, as I don't want to loose points only because I didn't make all assumptions (and assumptions can be made recursively ad infinitum ) etc.

-----------
Komandir Kozlov
SCJP, SCWCD, SCBCD, SCEA (1)



IMHO it would be un-realistic to design a system without DB, even simple flat files can be considered as DB, since storing information in permanent way is always required. In this particular case (I'm also working on this assignment) the DB is mandatory for storing user account's details (even it's not mentioned in use cases it's obvious the user need to authenticate) and also order information, e.g. when you close the browser before checkout and enter the website again next day/week it still keeps your shoping cart, right?

Suresh Gopal wrote:Hello all,

I am currently working on the assignment, and just wondering whether I need to include the some Design Pattern classes in the class diagram ?
For example, I can include the ServiceLocator class, but I am little hesitant since it might clutter the diagram.

Thanks in advance.


It's explicitly mentioned in Sun's site that you should include important design patterns in your class & component diagram. IMHO service locator is useless in JEE5, since injection (@EJB) removes the need of JNDI lookup, which is the main purpose of service locator.

Monu Sharma wrote:Some of my questions to start with?

1) So Big smokes cigar wants to establish an eCommerce site?
2) Does the inventory system of BSCS going to talk to inventory of other manufacturers via JMS?
3) To check the availabilty of cigars from other manufacturers, we need to establish a JMS Topic-right?
4) Can we use AJAX for front end or we need to use something from JEE stack only like JSF only?
5) use cases that are coming with the assignment-are they enough-or do we need to create more use cases based
on all possible scenerios?
6) Should we use sequence diagrams or collaboration diagrams? I have read most of the people use sequence diagrams
only.
7) Should we use EJBs or POJOs?



1) I would say yes, but not only, since there is complex back-end system also, it's not just a web site, though
2) It seems logical and would be good this to be mentioned in assumptions section
3) No, it's seems like P2P communication (check the availability one by one manufacturer, not subscribe for notifications when there is new provisions) , hence it should be Queue.
4) I think it's good idea to use AJAX for refreshing availability on the web page or other simple tasks. Even in JEE 5 there is no standardized solution this doesn't mean it's forbidden, because it's not part of the platform. By the way in JSF 2.0 (from JEE 6) there will be AJAX integration too.
5) Well, it's suppose that a business analyst created the use cases according business needs, hence the architect won't be responsible for use cases and shouldn't create new, since he/she is not competent in this area, IMHO.
6) It's up to you since they shows the same information from different view, but for me personally Sequence diagrams are more human (developer) readable
7) Well, again it's up to you, but my approach is to try using always POJOs except when it's necessary to use transactions, persistency, security or any other service that application server provide out of the box, means that a Transfer Object doesn't need any service from app server or DAO or Business Delegate, you could see in Core J2EE Design Patters book, that for every design pattern there are different strategies for implementation - POJO or EJB, so it's according the current needs, e.g. most of the cases Session Facade is implemented as Stateless EJB, because it needs to be called by the presentation tier. Well, POJOs are much lightweight than EJB, so if there is no special need you should use POJOs, I think.

In general, the decisions that you're taking on these issues are exactly the exam - there are always benefits/drawbacks and your job is to come up with argument solution.

Regards
Rumen

Monu Sharma wrote:I have some doubts regarding "Big Smokes Cigar Shop". anybody else also working on this?


I'm working on this assignment too. What doubts do you have?

ruben delcastillo wrote:Can be whizlabs trial version taken seriously about the questions it has ?

In evaluation test i think, they have reutilized question of previous version as well, and i have seen question about Jaxb ,jaxp,and stax and i don know if they are really related to specification J 5 EE or are related to SOAP, or Web services generic question.

So i think it is a guide to the exam and i dont know if test are more harder than exam or different topics or questions.


The trial is very similar to the full version, since the questions db is the same.
JAX-WS, JAXB, JAXP, StaX, JAXR are important and relevant for the JEE 5 SCEA exam, I've got 2-3 questions on this topic.
The real exam is much harder than the simulator. These 100$ worths only if you want to find you weak topics and to get some confidence. Perhaps you'll be disappointed also of the low quality of the simulator (wrong descriptions, wrong answers, contradicted answers, duplication of questions, etc).

Cheers
Rumen
Thanks for the answers!
Well, I'm not impressed so much of Whizlabs solution, there are couple of wrong descriptions in the questions, some obvious mistakes in the answers and feeling of too piece-of-cake questions, I'm sure that score of 85% which I received from the simulator won't be achieved on the real exam, but at the end it was good exercise and I understood that "integration and messaging" shouldn't be underestimated nor any other topic (like JCA or StaX). If the authors put some efforts on the quality and raise the difficulty the simulator would be perfect.

Cheers
Rumen
I've both books that you mentioned, but they're for the previous version of the exam, I understood that the current version is more scenario oriented, this is something that bother me.
Hi folks,

I'm not enough confident in my knowledge for the exam, do you think Whizlabs SCEA 5 exam simulator will give me relief? Is it good enough to trust it in case I pass with more than 80% in the simulator, I'd take the real exam too? How close are the questions to the real ones? Or maybe I could find my weak points with the simulator. Does it help really?
Thanks for the answers