SPAD

Here is what I think : [if I understand your ? correctly]
What is the probability of the subsystem being replaced with a better/enhanced/moreCompatible system in future ?
If its very high or even moderate I will go with a design that will provide me minimal coupling. E.g., you may add an abstract layer that will be implemented by the future submodule design to interface with the system you are designing. For using the current submodule you will have to write adaptor(s).
As indicated previously JCA is an abstract layer that provides you (& containers) a universal access mechanism to data sources. JCA may be done for RDBMS and thus replace JDBC. Yes that is an abstract layer already available for use. But writing the implementation for JCA for accessing your sub module will not be a trivial task. And ask yourself is it really required to be so general I will prefer to create my own simple to implement/use layer whenever possible.

I will repeat what I have learned - DAO are for putting your logic for accessing the data.
Now if you think your components have a need to access the datasource use it as its the best way.
So your question boils down to :
Whether you should access the datasource/db from your stateful bean ? Why not if there is a need ?
E.g., there might be a business logic that need topick up some values/data for calculation from DB.

I think its the terminology that is confusing yall
If you go by the definitions as per TCP/IP theory you will find that a connection oriented means something like a telephone connection wherein there is a handshake involved (such as saying hello) before the conversation starts. This is what a stream socket is - the other or connectionless is like a letter you fire and forget i.e., datagram socket.
At application level protocol a connection oriented means a protocol that maintains a conversational state where as a connectionless means no conversational state is maintained irrespective of whether a stream/datagram socket was used.
HTTP is application level protocol - now you decide

"3270" terminals based apps are generally refering to monolithic cobol/mainframe applications. These applications are based on screens; the user need to know the name/id of the screen that they want to use - there is no concept of hypertext or links that makes these screens really cumbersome to use and the learning curve for such systems/apps is very steep.
Moving away from 3270 means more than just moving to a GUI application. Obviously that is one big reason. Can I have a friendly user interface without using GUI - yes checkout the banking applications written in DBase/Clipper

Chris you are 100% correct...
i will add ...

Your message was edited since you quoted content from the actual assignment. Please read our policy on SCEA questions and refrain from discussing actual assignment issues.
Thank You!

[ August 13, 2003: Message edited by: Ajith Kallambella ]

Depends on your objective:
(i) Just clear the test and be satisfied - concentrate just on the cert objectives
(ii) Learn and apply - feel good - spend time on anything and everything that will help in making you a better architect/developer.

Byran,
Thanks for the FYI - I will wait for the Punch
Anyway how about adding the following choices:
(i)May be removed from memory that is "Does not Exist" (true)
(ii) May be put back to the pool (true)
(iii) Always put back to the pool (false)
(iv)Always removed
(v) Converted to a Statefull Session Bean
Cheers,
SPAD

----------------------------------
There's no need to leave the pool, because there is no assignment. Each one is equivalent, there should no variation in state, so any instance can service any client, thereby negating the need (...and the overhead) of assignment.
----------------------------------
Byran,
In that case there is no need to even maintain a pool of these beans a single instance can serve request on behalf of all the clients ???
IMHO this is one of those no-right-no-wrong question. This behavior is defined in the EJB specs in a flexible (implementation POV) fashion like many others. Here is a quote from Monson's book:
Page#239 /Second edition
"Stateless bean instances enter the method-ready-pool as the container needs them. When the EJB server is first started, it will *probably* create a number of stateless beans and eter them in Method-ready-pool (The actual behavior of the server depends on the implementation). When the number of stateless instances servicing the client requests is insufficient more can be created and added to the pool".
Now there has to be a maximum and that is the reason I supported the idea of removal or "Does not Exist" state.
-------- ----------------
Regarding the Assignment
-------------------------
The Bean when servicing a request from one client is unavailable for use by any other client i.e., it is assigned to that client & there is a good reason why it should be.
Monson's book again Page# 240 second edition -
" When a client invokes a busines method on an EJB object , the method call is delegated to any available instance. While the instance is exuting the request, its is unavailable for use by otrher EJBobjects."
----
When the bean is removed
------
Monson Page# 241 Secon ed
"Bean instances leave the Method-ready-pool for the does not exist state when server no longer needs the instances. This occurs when the server decides to reduce the total size of the pool..."
Regards,
SPADer
[ July 25, 2002: Message edited by: SPAD ]
[ July 25, 2002: Message edited by: SPAD ]

Bryan,
expose via Servlet that is what I suggested not code in a servlet - you still need to wrap the legacy access in business delegates i.e., re-useable in any app or component e.g., even in a EJB
Regards,
SPADer
[ July 25, 2002: Message edited by: SPAD ]

IMHO
A simpler solution will be to create a mid-tier that would deal with the legacy communication and expose the domain/data etc For example via Servlets. This will enhance re-usability and will scale better.

"C" is the answer - read Emil's response :-)

Ans is 2 but here is some food for thought -
Lets say we have an Entity bean that has name as one of the attributes and a finder method is there that finds all the beans that have "name" starting with "particular alphabet" lets say "A". Lets say the query was fired by two clients and the result set included three beans :
name=Alice
name=Alison
name=Alisa
Now one of the client called the set method and changed the third bean to
name=Kalisa
So now the PK is still the same and the second client which is printing out the query results to a brower UI will give out incorrect info which may prompt the user of the application to open up a bug ticket:
User asked for name starting with "A" and he/she recvd:
name=Alice
name=Alison
name=Kalisa

Ans-1
JMS is an API the concrete implementation is provided by the vendor e.g., MQSeries provides its implementation in two Jar files available as part of MA88 package. As JMS user you need not concern yourself with the concrete classes or in other words the vendor. [yes the factory need to be specified]
-----------------------------------------------
Ans-2
Some MOM products such as IBM MQseries requires you to install a server which may be on the same m/c or different m/c. Now n/w connectvity has to be there between the producer and the middleware server but its not neccesary that the consumer is up and connected to the middleware server. E.g., the consumer may be a travelling salesman's application. So what happens to the message. A message has an expiry if it is not consumed within that time it gets removed and is made unavailable. As and when the consumer connects to the middleware it can accept/get the message(s).
-----------------------------------------------
Ans-3
The synchronous messaging model/API allow you to recv messaged synchronously i.e., when you invoke a recv the calling thread gets into a blocked state. Using this you can write a thread that can poll a queue for messages.
What if the Vendor provided you with an already implemented polling mechanism ? Its there the asynchronous model wherein you register a message listener on a reciever and your listener is invoked as and when a message is recvd. The idea is that now you don't have to write your own polling mechanism and there are other benefits which is out-of-scope of this discussion

The returned Enumeration/Collection has the remote references that doesn't neccesarily mean that the corresponding beans have been created. The beans may be in passivated state [no resource usage] and will be activated only in case of business method invocation. Check this out in Monson's book on EJB "The Life Cycle of Entity Bean" on I think page #213 secod ed

HTTP is Connection-oriented and Stateless protocol.
Using the layman's example Connection-oriented is like a telephone call i.e., before you can talk you have to establish a connection i.e., TCP/IP Sockets type for HTTP. In case of connection-less think of it like a letter that you put in the post-box - if everything is fine it gets there but you don't expect an immediate response i.e., TCP/IP Datagram sockets. Now you can tell whether HTTP is connectionless or connection oriented.
Stateless - everytime there is a HTTP (1.0)request from a browser client a TCP/IP connection is established data is sent back and connection is dropped. Next request comes in the server doesn't knwo whether its related to any of the prior requests or not ... i.e., inherently there is no state being maintained by the HTTP Server. Now your argument would be what about cookies or URL re-writing ? That is an extension to HTTP protocol.