Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Deployment Diagram and Clusters

 
Antonio Rafael Rodrigues
Ranch Hand
Posts: 74
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello =]
I have three questions:

1) Do you know a UML compliant way to represent a Cluster on the deployment diagram? All examples that I found in the internet weren't UML compliant or weren't conceptually correct.
2) I think the correct way to represent the conversation between the application servers to the external systems and database is a line from the cluster to the external system and not from each server. Am I right?
3) Did you represent the admin server in your assignment? I think that in any application server that supports clustering there must be a server dedicated to administrate the cluster. It can run in a JVM on the same machine as one of the other servers (nodes) or have a dedicated machine. Did you show it?

In my humble opinion I think the best way to represent it is as on the attached picture.

But I've never seen this kind of thing in the internet. I don't know if I can represent a Cluster As a node that wraps two nodes distributed in other two nodes. I don't even know if it's UML compliant.


Thanks.

DeploymentDiagram1.png
[Thumbnail for DeploymentDiagram1.png]
 
Andres Olarte
Ranch Hand
Posts: 46
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Antonio,

My answers are mostly my opinion, but hopefully they will help:

1) The Cluster could be a component (using the component 3d box widget). In the component you would have the machines, and inside the machines you have your app servers. Conceptually correct? May not 100% UML compliant 100%? No idea. But it would help show how it works. You could do something non compliant, like use a dotted box to represent what's part of your cluster. As long as it conveys the clear intention, I would say it's correct.

You could have only the app servers inside the cluster, but from an UML kind of way, it's weird, because of overlapping boundaries. Is the machine part of cluster? Not exactly, but the cluster can't exist outside of some machines. This arises from trying to mix two a "logical" deployment and the "physical" deployment into a single diagram. I would still keep it to a single diagram, but understand that you're mixing somewhat separate concerns.

2) It depends, actually each server connects to the database. It's not the "cluster". However, in terms of the diagram, I find your sample pretty evident in what it tries to convey.
3) Yes, I did show it. It's important to show it. In one of the node machines? In a separate machine? Well, look at your NFRs to see what's more appropriate, but I don't think either one is really wrong.

Good luck,

Andres
 
Antonio Rafael Rodrigues
Ranch Hand
Posts: 74
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andres,

First of all, thanks for your help.

I totally agree with you. You've mentioned a point that I didn't think before: The problem is the mix between a conceptual diagram and a physical one.
I liked the idea of a dotted box for the cluster (I've already had this idea.) and I still feel very strange about the ideia of a cluster wrapping two physical machines. The problem with the dotted box was that I couldn't link it to other components (it's prohibited in UML tools), but as I think you are right about that fact that each server connects to the database, I don't need the cluster connected to anything.
Then I'm going for the dotted box =]

Two more questions:
1) Since you showed the AdminServer, did you show the node manager as well? I think it'd be too much detail, but I'm not that sure.
2) I'm going for a Oracle RAC, but I don't know almost anything about the internal structure of it. Do I have to show the Oracle RAC as detailed as the weblogic cluster (with "nodemanagers", "adminservers", "deployed schema")?

Thank you.

 
Andres Olarte
Ranch Hand
Posts: 46
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Antonio,

1) Well... that depends, are the node managers significant for your architecture? For example, if you were sending emails, then the SMTP server should be shown somewhere in the component diagram. Will the node managers help you achieve a functional requirement or a NFR? If yes, then add it. If not, then you can skip it.

2) The same thing would apply to the Oracle RAC. Is any of those subsystems vital to your architecture? Are you doing anything esoteric with it? Otherwise you can treat it as a black box. This how Oracle expects clients to access the RAC, as a single black box, not hitting directly any of the underlying pieces. However, if you have some special communication going on to figure out which nodes are up, synchronization status, then it might be worth detailing those specific resources. I'm on the

Good luck,

Andres
 
Antonio Rafael Rodrigues
Ranch Hand
Posts: 74
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andres,
Thank you again.

1) I understand your point of view, it really makes sense. But if we see the things from this side, why would we need to show the adminserver? IMHO, a adminserver don't directly help me to achieve any NF or NFR. It "manages" the cluster and the cluster helps me. What do you think about this thought?

2) About the database.
Do we have do specify the database hardware? (I've never questioned this). If yes, it'd be strange show RDBMS as a black box. If not, it makes total sense.

Thanks,

Antonio

 
Andres Olarte
Ranch Hand
Posts: 46
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) I would say with 100% confidence that the manageability is a NFR. Does it apply to you? That depends on your scenario. (I'm assuming you're talking about a Weblogic domain in this case, but I might be wrong) Can you get away without having an admin server? Actually I think you can, I have never done it, but I've read of people that move the config.xml manually from a staging environment to their production environment, and don't have an admin server in production. Of course they also have figured out other ways monitoring and troubleshooting the cluster without the admin server. Either way, I think it's worth addressing the NFR of manageability. The admin server is one way.

2) What you're saying makes sense. And it all goes back to your assumptions. Are you relying on a DBA team? If you assume so, then it's easier to treat the DB as a black box. Are you assuming that your the only technical person in this fictional company? Then you're on the hook for dealing with the database stack (hardware / software / etc). Both cases are valid in the real world (I've had to deal with both). In this case, you make some assumptions and focus on the core of the assignment, which is Java EE architecture. In my opinion, for the assignment, going into great detail about the database is not required (unless your architecture depends on some special DB feature or setup).

At the end of the day, the idea is to have something that someone can pick up and understand.

Good luck,

Andres
 
Antonio Rafael Rodrigues
Ranch Hand
Posts: 74
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Andres

Thank you again, this thread is being very interesting.

Admin Server brings manageability. Yes, I totally agree.
I've never thought that it was possible to not have a AdminServer. Since it's possible, I agree that I have to explicitly show that I have one.

Thank very much.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic