Thanks for your interest in the project! Some responses in-line:
On 7/9/2014 10:01 PM, Naresh Kumar wrote:
> Hi Rahman,
>
> Are there any UML diagrams for better understanding of Cargo Tracker
> example provided in java.net <http://java.net>. as a reference
> implementation for Java EE 7?
I have just a few diagrams here:
https://java.net/projects/cargotracker/pages/Characterization. Other
than that, honestly I don't plan on doing much diagramming. As such, MDA
is a little anti-DDD, anti-agile (for good reasons) so we try to avoid
it. The best way to learn the project is really just exploring the code:
https://java.net/projects/cargotracker/sources/svn/show. It should be
fairly understandable thanks to DDD (but it helps to understand DDD first).
>
> To debug the application what are the settings required?
Just use debug via NetBeans or some other IDE?:
https://weblogs.java.net/blog/2007/06/18/debug-application-code-deployed-glassfish-using-netbeans.
>
> From the dashboard.xhtml using listRouted.js has a javascript
> invocation of WebSocket. It invokes RealtimeCargoTrackingService.
> Based on the URL from the application WebSocket implementation class
> is invoked right? Why not any design pattern is been used.
I think I sort of understand what you mean. RealtimeCargoTrackingService
in DDD terms is an interface that uses the Cargo domain object. Other
than that, there really isn't a need for further abstractions on the
server-side. Do you feel differently? Now, we could use a JavaScript MV*
framework on the client side. In fact, this has been on my to do list
and would be a nice community contribution :-).
> The way I see WebSocket is a kind of stateful session bean, I
> understand the differences between WebSocket and Stateful Sesson Bean.
I'm not entirely sure what you mean. A websocket endpoint can be a
singleton (ours is a singleton) but not a stateful session bean or a
stateless session bean (not yet anyway). You can also have a WebSocket
endpoint that is tied to a single client, which is sort of like a
stateful session bean but really more like a CDI request or session
scope bean.
>
> Even the same thing is followed for RESTful WebService. RESTful
> webservice is a stateless session bean generates a JMS event and sends
> a message to JMSQueue, HandlingEventRegistrationAttemptConsumer based
> on the event uses their concerned stateless session bean.
I've really lost you here unfortunately. The HandlingReportService is a
DDD interface. It generates a domain event
(HandlingEventRegistrationAttempt) from a DTO (HandlingReport) and uses
an application infrastructure abstraction (ApplicationEvents) to
generate a JMS message. Do you think we need more abstractions? Now,
granted again that I was going to use a JavaScript MV* framework on the
client side at some point.
>
> Objective for the above things of WebSocket and RESTful webservices
> the requests are not going through Controller (FacesServlet) if my
> understanding is correct.
JAX-RS and WebSocket endpoints do not really require a controller as
they are essentially interfaces on their own right and are not part of a
UI. A controller would come into play where there is a UI (such as in
JSF backing beans). Now if we were to apply a JavaScript MV* framework
on the client side that would certainly have a JavaScript controller of
some sort. Is that what you mean?
>
> It will be grateful if you provide these information.
No problem - I hope the above helps. If not I can try to clarify further.
>
> Thanks,
> N.Naresh Kumar.
>
>
>
>
>
>