Srinivasan Rengan

Ranch Hand
+ Follow
since Nov 07, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Srinivasan Rengan

People,

I have a quick question. I have a requirement where the facade needs to send an async request to an internal queue.

Now, how should the component diagram look like?

I am showing the queue and also the facade class. But I am not really happy with an idea of showing an interaction between them directly. So I use an adapter class. Now the point is, can i show up the adapter class in the integration tier?

In short,

Facade (BI tier) --> Adapter (INT tier) --> Queue

I cannot use a DAO here because I am making an async request which logically does not sound good with DAO.

Thanks in advance for your help.
Appreciate your replies.
Srini
Hey Luke!!

Take for instance a shopping cart app. I may have a state object (in form of Order or Cart etc etc) specific to the implementation. Keeping this as part of the SFSB would make my managed bean thin.

But my application might have other state information which might not need a SFSB. For instance: I might maintain a login authentication code or attribute. This might not actually make my managed bean fat.

This is purely my perception and I am happy to hear that it is wrong too!!

Thanks
Srini
Hey Srivastav!

Thanks for your replies...they were spot on!!

I have few more questions here:

This is my situation:

My component diagram follows the tier approach (Courtesy: Humphrey Sheil)

In BT (business tier) having one inventory related facade...Now this facade does two things for me...sync request and also async
request...In order to get from an internal inventory system it does sync request...for sending a another type of
request (secret LOL) to an external system sends a async request...

For the sync request I thought of having an DAO which makes more sense...so did that..but for async request i send a request to
the external queue...I thought I should use an adapter here...So in this case, i put the queue adapter in the integration
tier...Does this sound sensible?

Also, another question which I get here is...how do I show the interaction between the external queue and the adapter...I mean..how to depict that in the component diagram? Can I just use a <<uses>> here? (Humphrey Sheil does that...but he just uses DAO classes in the integration tier...)

Thanks.
Srini
Hi All...

Thanks for all your responses...

I am thoroughly convinced that Visual Paradigm Community edition is a wonderful tool

Star UML is also good, but for the complete compliance to UML 2.0, VP scores better :-)

Thanks
Srini
I am using Star UML for building my component diagram. I liked the tier based grouped approach of Humphrey Sheil. But unfortunately starUML does not assist with the complete support for UML 2.0 (at least from component diagram angle)

Now I am trying to mimic Humphrey Sheil's diagram using a Annotation rectangle and a normal component box put together. But I not fully convinced with this.

Any one else found or still finding the same difficulty? Any alternatives welcome!!

Thanks in advance!!
Srini

Jeanne, no one can deny the scalability efficiency of stateless session bean. But i was wondering if this has a bold in the blue point about session management:

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html

Under the section ( Web-Tier State Recommendations in the above link) and further down, the recommendation has been in favour of SFSB.

Would invite your comments on the same.

Srini
I have the same quesion in my mind.

Thinking about it, If we have only HTTP based client (not any other non HTTP clients) accessing the business component, then we can maintain state in HttpSession.

This is a point on which most of the websites concur upon too..

But ,would be watching this thread for further inputs on this..

Few queries about the sample application in Cade's GES system:

1) Product(*) -> ProductCategory(1) is what is shown in BDM but in the actual class diagram it is many to many. More probability of being a typo, right?

2) Where does the Products and categories load from? Can we assume that these are entities and hence are loaded from the DB? Only when the user selects a product or category, their availability is checked against the external system?

3) Manufacturer is an attribute inside the product: Agreed. But would I be wrong if the class diagram still holds the Manufacturer class and a One-to-One relation (Unidirectional) with the product class?

Thanks in advance for your suggestions.
S.
Hi All,

I am designing my component diagram in the way Humphrey Sheil had done it. I found that way of representation very simple and effective.

But unfortunately starUML does not allow that to happen.

I am trying to indirectly make it happen by using the rectangles in starUML annotation and placing component inside. But unfortunately the rectangles don't accept dependency relation.

Any thoughts about a work around or any other tool would greatly be appreciated :-)

Thanks
Srini
You mean the MDB or the adapters?

Also, if I have a requirement to show up a JMS Queue as part of my own system (Not external), in such a case should I show that up in class diagram? Also what happens in sequence digram?

Thanks in advance.
Hey Thanks for your reply..

I have an MDB. On receipt of the message it sends message to multiple external services. These services could be JMS based services or even mail servers.

Now I have adapters for all the above mentioned list of external services.

My query is that if we are using these adapters, can we show them into the integration tier of the component diagram? As a service locator my MDB would qualify. I have few DAOs which would also qualify. But these adapters...would they qualify as helper components?

Hi All,

DAO forms an elegant pattern when it comes to integration tier.

I was trying to bring in service activator into this tier, but faced with a small query.

Can we bring in both service activator and adapter into the integration tier [service activator (which could be a facade class, probably an MDB) using a adapter to send messages to external services]?

Thanks
Srini
Hey Carlos,

With regard to the Jewelry Enums..I had the same confusion last 2 weeks and I would suggest what I have discovered.

In the assignments there are few hints which you have to watch carefully. The hints might be in regard to the use cases. For example, there might be a use case which might actually ask you to fetch categories or types of jewelry.

So it makes sense to see these classes as types ;-) [Just a thought]

Srini.
People,

Here is my doubt about the integration tier. I am planning to implement a service activator and as per Humphrey Sheil, I can show up a MDB in component diagram. Now my point is, should we also show up an MDB in class diagram?

Also, how about the JMS queue to which the MDB is listening to? Where do we show that? Now important thing about this queue is that it is part of our system and not an external system.

Also if a adapter is being to access an external queue or a service, then the sequence would be:

Controller -> Stateless Bean - > Queue - > MDB -> adapter -> External queue or any other service.

Makes sense?
Your inputs greatly appreciated.

Thanks
Srini
I was reading another post and I found that too good. The post which was suggesting about treating the cigars as categories. In that case we can actually consider the existing entities to be subclasses to the category class (simple IS-A relationship)

But the only question which I have here is, why not the question be straight forward? It could be complex, but that need not make it more confusing