Marcin Cinik wrote:Thanks Eduardo,
For JMS I would just give "JMS API" as required interface (even though JMS API is not an interface).
When it comes to JAX-WS generated client I propose to have "javax.xml.ws.Service" as provided interface.
The deployment diagram should rather depict machines / application servers / protocols / DMZ / firewalls / load-balancers in my opinion.
shekar hari wrote:Congrats....do you know what is "part 3 short answer" in part 2 exam? Is it part 3 exam? For part 3 exam, do we need to wait till we get part 2 exam results?
shekar hari wrote:How soon you waited to take part 3 after your part 2?
Amandeep Singh wrote:Since the question says which is the design pattern to avoid having lots of conditional statements, then Builder Pattern makes the sense, I wasn't knowing about this earlier.
An essential part of our grand plan of avoiding ugly if-else blocks by means of polymorphism is to embed the varying functionality into the different implementations of the polymorphic concept of Segment objects. (Test Driven: TDD and Acceptance TDD for Java Developers, p.123)
Risk is the possibility of a negative or undesirable outcome. In the future, a risk has some likelihood between 0% and 100%; it is a possibility, not a certainty. In the past, however, either the risk has materialized and become an outcome or issue or it has not; the likelihood of a risk in the past is either 0% or 100%. (Foundations of Software Testing, p.151)
Risk-based testing involves both mitigation - testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects - and contingency - testing to identify work-arounds to make the defects that do get past us less painful. (Foundations of Software Testing, p.152)
Eduardo Mineo wrote:-1, passed after resubmission. I'm very disappointed with Oracle in so many ways, but later I'll write about my certification process. Thanks everyone whom contributed to this wonderful forum.
joey cole wrote:How long did you have to wait for the results of your resubmission?
When SFSBs should be used in web systems
Systems that have JSP/servlet front-ends should use HttpSession objects to store session-oriented state on behalf of a client. Applications that manage an HttpSession object and an SFSB for a single client wind up duplicating effort that does not need to be duplicated. There are two reasons to use an SFSB in conjunction with an HttpSession object:
Your application server does not provide cache management of HttpSession instances and your system is expected to have a large number of concurrent clients. Containers for SFSBs can activate and "passivate" the state of instances to and from a secondary store. This allows a container to create an upper limit to the number of instances that will exist in memory at any given point in time. The number of concurrent clients can exceed the limit of SFSB instances in memory because the container can swap idle instances to and from the secondary store. The container will never allow more than the limit of SFSB instances to exist in memory, subsequently placing all additional instances into the secondary store. This provides a greater level of scalability to the system through effective memory management.
Many application servers provide similar cache management of HttpSession objects. Because HttpSession objects are similar to SFSBs, they can also be made passive and active. Cache management behavior of HttpSession objects is not required as part of J2EE and is considered a vendor value-add. If your application server does not support HttpSession cache management -- and you need to control the total number of session-oriented instances in memory at any given time -- you should place the bulk of your session-oriented data in an SFSB instead of an HttpSession object. You will still need to maintain an HttpSession for each client, but the only item in the HttpSession should be a reference to the SFSB for that client. If the only item in the HttpSession object is a reference to the SFSB, the amount of memory consumed by each HttpSession object is minimal and cache management of these instances is not needed. The bulk of memory consumption will occur within the SFSBs, which have a standardized strategy for allowing a container to perform cache management.
Your session-oriented objects need to receive notifications on the lifecycle of the transactions they participate in. SFSBs can implement the SessionSynchronization interface. The SessionSynchronization interface contains three methods that a container invokes as a transaction migrates through the lifecycle the SFSB is participating in. An SFSB might implement the SessionSynchronization interface as a way to return the data of the SFSB to its original state whenever there is a transaction rollback. HttpSession instances do not have a mechanism that allows them to receive transaction notifications. This means that any data that is modified in an HttpSession during a transaction will not be reverted if the current transaction is rolled back. All changes to data in an HttpSession object are always durable despite the outcome of any executing transactions. If this behavior is not appropriate for your system, placing all data into an SFSB instance that implements SessionSynchronization will give you the appropriate behavior.