Win a copy of Fixing your Scrum this week in the Agile forum!

kaiser eblovich

+ Follow
since May 28, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by kaiser eblovich

Thanks a lot, Jaikiran!

Yours is indeed a most elegant solution I could imagine.
14 years ago
We're building an application (Management Console) that will be managing other applications deployed JBoss instances running on remote nodes.

There's JMX interface and MainDeployer MBean (didn't check JSR88 stuff yet).
An application is deployed by deploy(URL) method of MainDeployer, so all I need is to expose EAR to be deployed from Management Console via http and pass its URL in a remote JMX call to MainDeployer.

However, there's a problem.
Applications being deployed in such a way are stored in /tmp directory (looking at MainDeployer code just confirmed it) and when the server is restarted, they just vanish!

Of course there are a couple of workarounds, most silly thing I could think about is a tiny 'agent' application that will reside in remote JBoss, accept application to be deployed as file upload and then put it into server's /deploy directory. But this is kinda ugly, with all that jazzy JMX around.

Better solution, anyone?
Many thanks in advance.
14 years ago
The container can choose to passivate an entity bean instance within a transaction. To passivate an instance, the container first invokes the ejbStore method to allow the instance to prepare itself for the synchronization of the database state with the instance�s state, and then the container invokes the ejbPassivate method to return the instance to the pooled state.

ps. google is your best friend
no guys, they are not
(for the UC diagrams are describing the behaviour of the system, and the behaviour is inherently dynamic)

Kaiser Eblovich,
Sun Certified Everything
Yes, I did draw an MVC pattern there.
It seems like you already know what you want, don't you?

SCEA certification [still] looks impressive to those management types, so go ahead and to it.
On the other hand, SCEA part I contains ~30% questions about EJBs, so if you did SCBCD you can easily try SCEA part I as well. For both SCJP and SCBCD there are good books available, so if you got 3 years experience, it's about 3 days of preparation for each exam.
No, no, oh god, no.
You _don't_ have to put logging, exception handling, monitoring and other stuff into your diagrams. My component diagram was 20 components of even less than that, pure generic things like Command or ConcreteValueObject.

In first attempt I've put six entity beans into persistence layer, in second it was a little more than six and I thought, what the f***, and there was just one ConcreteEntityBean instead. You might believe me or not, but in both cases the result was the same, 42/44.

In other words, your diagrams must be _complete_, that means at the chosen detail level they show all relevant parts. But they don't have to be _detailed_, because it's architecture (conceptual level), not design (blueprint of a complete implementation of functional requirements).
Well, whether Sun's approach to architecture is right or not, this is a subject for separate discussion.

I've done enough real-world systems and I've never seen the system where the approach with domain object diagram was useful for anything but first analysis phase. The actual DB schema is always tuned for performance and might be anything from 5 tables per entity to 5 enitites in the same denormalized table.

with the sequence diagram you show the dynamic behavior of the static class diagram

In this case - it seems like no, you do not.
You show dynamic behaviour of your _components_, I would even say _types_ of components. The value of such diagrams is questionable, maybe just to validate that all external systems are covered in your component diagram.
I don't think you'll have 10 components using your mail component.
In my architecture, it was only one. Anyway it's up to you.

You can read my explanations in this topic
They say agent's clients (GUI apps) are running on internal network (look into assignment for exact phrasing) so I'd say there's no need for secure sockets there.

1. Can I put some common components, for example, a mail component without any connection from other components in my diagram? cause it's a common component. Its dependency will be defered to the next stage other than architecture stage.

I guess your mail subsystem is there to be used by some other component, implementing [a piece of] business logics? So that other component will _depend_ on your mail component. What do you mean "dependency will be deferred..."?

2. I've had interfaces in front of many of my components. Even components not for connecting to external systems (For example, controller --> interface--> delegate). I'm wondering if it's acceptable? Or interfaces just should be used for linking external systems?

The only interfaces I've shown were those related to EJBs, session and entity beans. I didn't use any other interfaces in my component diagram and got 42/44 for it. Components were tied together by dependency relationships, to show who's used by who.

Originally posted by David Follow:

I thought you have to show how the classes from the class diagram interact by drawing a complete sequence diagram, meaning an SQD with *all* participating classes. So from what you said, you only showd "layers" but did you also show concret classes from the class diagram in your SQD?


Well, I thought that as well
But then I read notes from some smart guy who did it with layers and got through, nevertheless.
No there were no concrete classes from the class diagram in sequence diagrams, and moreover, class diagram as Sun understands it just _doesn't contain_ all the stuff like View and Business and Persistence. They understand class diagram as analysis model, more of domain entities you have to deal with, and it has nothing to to with sequence diagrams.
Two points for you to think about.

1. They say "FBN would like to make the user interface more appealing for their travel agents by replacing the 3270 terminal with one that can support a graphical user interface". Graphical user interface -> GUI client -> Swing. Though one might argue (and I even would agree to) whether a browser is sort of graphic user interface as well, especially with advent of RIA and alike, but it's clearly not what they meant then back in 2001 when this certification was planned.

2. Everyone I know who passed SCEA (including myself) did use Swing client.
I personally won't trust anyone with only SCEA, without SCJP/SCBCD.
As I said I thought that the class diagram must contain what the class diagram supposed to contain - classes. I mean all those Actions, Sessions, CommandHandlers and other stuff which according to Sun belongs to _component_ diagram. That was my fault. I've redrawn the class diagram into absolutely stupid thing with domain entities and got 42 points.