Bill Morrison

Gentlemen,
I have been reading several sources on depicting J2EE components and systems in UML. At this time, there seems to be several approaches with little formality beyond that which UML itself provides. Find "UML Profile for EJB" for a draft spec from Rational. Also, "UML J2EE" on Amazon yields a couple of good books.
To the point though, UML provides the notion of stereotypes that allows us to use shorthand notation in modeling systems that are based on defined types.
The question might be: What are the stereotypes that readily recognized or otherwise needed to be defined?
Regards,
Bill

Darryl,
I.M.H.O.!!
The architect should take the stance that would provide the deliverables that are required. Typically, architecture deliverables do not require detailed alternatives. Rather, the architect should propose a design that can be rationalized based on both an understanding and an evaluation of the issues that arise from possible scenarios.
The architect must recognize the risks and difficulties of building the system and then provide the developers an effective and efficient way to build the system and its subsystems. This can be tantamount to providing a rigorous system structure that incorporates one or more frameworks for subsystems. The framework might be incarnations of various design patterns that address the problem space of a particular subsystem. The developers chore is to adapt to the rigorous system structure and to design and build components that based on the framework patterns available within each subsystem.
Regards,
Bill

Eduard,
I think servers in the DMZ should also serve as proxies. In other words, they should not only convert HTTPS to HTTP, but also to look at each HTTP request to determine if it is acceptable. Of course, the devil is in the details. But, I don't think there is significant security risk in providing a very thin web tier front-end in the DMZ. A good design would assure that system resources in the DMZ would ward of denial-of-service attacks, etc. Only valid requests (I'm still thinking RMI-IIOP) would pass thru the second firewall, which serves to protect the valuable assets.
Regards,
Bill

If we first assume that one or more web servers behind a firewall are responsible for accepting SSL connections from the Internet, then it seems to me unlikely that their only other function would be to serve as mere HTTP proxies to establish HTTP connections to a web server behind another firewall. Instead, wouldn't we get more bang for our buck by having those DMZ web servers perform other functions like Internet client authentication and the lighter-weight front-end aspects of an MVC architecture? I would think that those web servers would communicate via RMI/IIOP through the inner firewall to the bulk of the business logic on the protected application server.
What do you think?

Another note here: I revisited the EJB 2.0 CompositeEntity issue. I have found one reference that argues that the pattern is still valid and one that cautions against its use. I'll need to spend more time on this to formulate an opinion.
-Bill

Eduard,
I agree. I don't intend to design clients in any detail. I'll leave that to the developers in the next iteration. I will only provide the architecture and design that meets the requirements as discussed.
Regards,
Bill

Debanjana,
I must admit that I perhaps don't fully understand your question.
However, I have read that it isn't a good idea to use the CompositeEntity pattern in on an EJB 2.0 platform. The issues are BMP versus CMP, course-grain versus fine-grain, and local versus remote interfaces. As Eduard points out, serializing references is a big issue and gets even bigger when you consider clustering and such.
My point here is, if I understand your question, strickly speaking the answer might be yes. However, I don't fully understand your question and the more likely answer is that you perhaps shouldn't do it without understanding the availability and maintainability issues.
Regards,
Bill

You are right, you won't find ejbCreate() in javax.ejb.EntityBean or javax.ebj.SessionBean, nor will you find the corresponding create() in javax.ejb.EJBHome interfaces. But, this doesn't mean that you don't need to implement them. The responsibility of the Bean Provider to implement ejbCreate<METHOD> in session beans and entity beans (where it is optional) is addressed in the EJB Specification.
Regards,
Bill

Guy,
Class diagrams, sequence diagrams, component diagrams, etc., are all intended to represent different views of the system. Levels of abstractions, static structure, dynamic interaction, packaging, and deployment are some of the differences that are addressed with different diagrams. Understanding what to depict in a particular diagram is usually a question that asks: What do you want to communicate and from what perspective?
Regards,
Bill

Guy,
As you've discovered, the SCEA Study Guide by Cade and Roberts doesn't attempt to teach you the design methodology that addresses your question. There are several very good books on UML and the methodology, including The Unified Software Development Process by the three amigos.
I have also found that Developing Enterprise Java Applications with J2EE and UML by Ahmed and Umrysh, and Building J2EE Applications with the Rational Unified Process by Eeles, Houston, on Kozaczynski helpful in understanding the current UML/J2EE mainstream.
Regards,
Bill

No. Well, yes. O.K. not really.
Not "everyone" agrees on when it is best to use entity beans, either BMP or CMP. Several of the books that I have used for reference give the standard guideline: a persistent data object that would benefit from the services of the EJB container (transaction, security, lifecycle management, etc. ). One book that goes a bit deeper into the pros, cons, and alternatives is J2EE Design and Development by Rod Johnson.
Regards,
Bill

Hi Mark,
I don't find a specific non-functional requirement that says Swing technology is required. Also, I don't find a specific functional requirement that might best be met with a Swing-based design. However, I do think it is clear that we need to support both "web clients and application clients".
I interpret this to mean that some remote clients will communicate with a web server, some will communicate with an application server, or perhaps even some will do both.
My approach to requirements analysis has been to consider the few "clear requirements" in a way that is specifically addressed in the design. Then, to concider the many "unclear requirements" as justification to include flexibility, abstraction, extensibility, etc. A clear requirement deserves an optimized design, an unclear requirement might mean a more resilient design.
Regards,
Bill

Hi John,
I recommend that you start here: Sun Certified Enterprise Architect for J2EE Technology Study Guide by Mark Cade, Simon Roberts.
This is, as it claims, a study guide which tells you what you need to know.
From some perspectives the breadth and depth of J2EE is unlimited. The guide will help you focus on what is most important toward understanding the J2EE architecture and accomplishing your goal.
The guide is only a couple hundred pages long. It does not attempt to teach you what you need to know, it only identifies what you need to learn. Which is one answer to your question ... by the some of the same people that were involved in the preparation of the certification that you seek.
Regards,
Bill

Good morning,
Have you completed part II/III? If so, would you please contribute to this thread?
Without giving away any details of your solution, can you please tell us to what degree you feel you adhered to or departed from the assignment instructions, business object model, use case specifications, TransMaster specification, and CEO/CIO interview? Did you strive to interpret these verbatim or in essence?
Thanks in advance to all who will reply,
Bill

Congratulations Andr�! I do have a question for you:
Without giving away any details of your solution, can you please tell us to what degree you feel you adhered to or departed from the assignment instructions, business object model, use case specifications, TransMaster specification, and CEO/CIO interview? Did you strive to interpret these verbatim or in essence?
Regards,
Bill
[ April 10, 2003: Message edited by: Bill Morrison ]