ntumba lobo

Hi
You are right with web service usually we have SOAP(xml) over HTTP, for EJBs it will simply be RMI the data being serialized.
To call your EJB the way you do it depends on the type of client.
But basically the idea is to do JNDI lookup to get a local proxy of your remote EJB.
In a server you can use dependency injection @Resource, outside a server you'll have to code manually the JNDI lookup.

I hope that'll help

the default is one instance per jvm

My guess would be that you have validation rules emdedded in your Customer class and the validation fails before persisting.
But it is hard to say without seeing the Customer

If I am getting this right your are talking about using a Messaging Endpoint, which is in itself a pattern for messaging applications.

http://www.eaipatterns.com/MessagingGateway.html

The messaging gateways dont have to be EJB-based

After the way you access the messaging gateways (HTTP or direct access) is up to you or requirements

Yes you can and I did it.
Well actually in depends on your type of Java client. In both cases the Client is running a JVM different to the running the application server.

If you have Java standalone application running in an ACC (Application Client Container) you can use annotations to inject EJBs coming from the
JNDI in the application server. The reason it works is that the ACC and the Application server are in close communication.

But if your java standalone application is running outside an ACC then it does not work as far as I know. You have to retrieve the remote EJB
by doing a manual JNDI lookup with the Initial Context initialised with the PROVIDER_URL of the relevant application server.

Unfortunately I dont have enough time to find you a step by step guide now, but I hope it is clear enough.
When I get the chance I'll add some more if you want to

I see, I think the process was still going when you killed it just at a very slow pace.
I had a similar case before.

Well in JPA/hibernate you have examples of specific code to handle big batches.
Basically you keep in memory only 1000 objects that you insert in DB, then you clear the memory and take care of the next 1000 and so on ....
After you know JPA generate a lot of SQL requests if you have a rich object model with plenty of relationships.
So you may want to check the SQL generated by JPA and make all SQL requests are really necessary.
I could improve the perf of my batch by leaving alone not necessary foreign keys

when you say the transaction never completes what do you actually get ? an error message ? if yes what is it ?
With more information around the problem we can provide a more appropriate answer

look at the JEE tutorials you will find ear files for the sample applications

It is a very low level technical concern, maybe not so relevant from an architectural point of view

You can put the level of detail that you want in the component diagram, it is totally up to you and there is no real wrong or right level of detail.
Just a level a detail which is appropriate to pass your ideas across (to examiner in that case).

I used the Cade's way in my assignemnt with only high level components (X DAO ) in the integration layer>.
I suited the design of my solution.
I then described in more detail these integration components in the class diagram.

Instead of using @Session I would rather use the more specific @Stateful and @Stateless, you could lose marks by not being specific enough.

As for the @application I would not personaly use it, I would stick to the default stereotypes @Entity, @Stateful, @Stateless, @MDB and the one for the JSF managed bean (@Managed ?) for the real component classes managed by the container. Any other other class that is not a component managed by the container is a regular class even if it comes from a JEE pattern.

Based on what I did in my own assignment ;-)

Good luck

welcome to the club !

well done !

If you do some research and go on the Oracle and the SCEA FAQ section of this forum you'll get the answers to most of your questions

I did use JSF in my solution but in the class diagram it did NOT show any JSF specific artifact.
I stayed very generic with Controller classes in my presentation tier.
After I just put a note on the class diagram to explain why I showed the presentation tier this way.
This is basically the Mark Cade's way.