In some articles on different sites i read that we only serialize/deserialize the state of object.On the deserialization side actual class definition should be present.
If that is the case, In case of EJB then how we get the Ejb home and ejb remote implementaion from server(which is on remote machine) as on client side we just have home and remote interfaces.
In addition to the home and remote interfaces, you need "stub" implementations of those classes on the client. These are generated in a vendor-specific way during application deployment, or in same cases, they are generated dynamically on the client. In any case, the server-side implementation is never needed on the client: when a method is invoked on a stub, the method request is sent over the network, and the server executes the logic when it receives it.
Related
I understand that gRPC is designed for client-server architecture. A server provides remote services and clients obtain the services by calling the defined RPCs. But is it possible for a client also defines a service so that other clients can request services from that client too?
An example, a server knows every client's locations and can inform other clients about the location information. A client, upon receiving the other clients' locations from the server, can now directly call the services provided by other clients.
Can gRPC do that? Thank you!
Yes, this is possible.
The terms "client" and "server" are overloaded in this context and would be better thought of as (stub) caller and (implementation) receiver. It's possible for the client and server to be the same process but then you don't need the complexity of gRPC.
There's no prohibition on some entity functioning as both a caller ("client") and receiver ("server"). This situation arises commonly, in peer-peer networks and in micro-services where some original client calls some service which (acts as a client and) then calls various other services ....
I am going through EJB specification(ejb-3_1-pfd-spec). I am not able to completely grasp concept of remote client:
Spec document states following:
"The interface used by a remote client of a session bean is implemented by the container as a remote business interface (or a remote EJBObject interface), and the remote client view of a session bean is location-independent. A client running in the same JVM as the session object uses the same API as a client running in a different JVM on the same or different machine"
This suggests that remote client can run in same JVM or different JVM from session object.
But different discussion threads suggest that a remote client is one which runs in JVM different from session bean.
So which definition is more accurate.
Any guidance would be of great value.
This is a bit reflexive - a remote client on JVM A on machine A is connecting through to an EJB component on JVM B on machine B, that's all either side is aware of. In some situations, it may be that machine A and machine B are the same machine. It may also happen that JVM A and JVM B are the same JVM.
The important thing is that remote clients are location agnostic - they must behave the same regardless of where they are on the network. As a programmer, this means your code must not assume they are in the same place. As a deployer, it means that you can choose to deploy them on one machine or on several, without any code changes.
I am learning Signal-R, and this is something that has been in my head during all time.
How does Signal-R fits in the IIS/ASP.NET life cycle?
How long does the Hubs live (I see they have re-connection semantics)?
Does IIS does prevent the shutdown of an AppDomain that has a persistent connection?
It is my understanding that IIS is designed to handle request-response scenarios. A request hits IIS, this finds the AppDomain, activate it, and then pass the request to it. And after an idle time, shutdown the AppDomain. If the request takes too long, a timeout exception is thrown.
Now let´s imagine that I have another application that broadcast information through a TCP socket. I want my javascript clients to get that information in real time, so I create a Signal-R web application. I can create a TCP client on application start, but what does guarantee that IIS is not going to shutdown the whole thing after some time with inactivity?
I could self host the Signal-R app in a window service, but then I would have to use a different port, enable cross domain, etc... Many problems for deployment. But, I am concerned about using an ASP.NET MVC application for this, since it looks to me like fitting a driving wheel in a motorbike.
Cheers.
SignalR in IIS/ASP.NET Lifecycle
SignalR uses Owin: http://owin.org/
A good article on Owin here: http://msdn.microsoft.com/en-us/magazine/dn451439.aspx
Hub object lifetime
From the SignalR docs: http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-server#transience:
You don't instantiate the Hub class or call its methods from your own code on the server; all that is done for you by the SignalR Hubs pipeline. SignalR creates a new instance of your Hub class each time it needs to handle a Hub operation such as when a client connects, disconnects, or makes a method call to the server.
Because instances of the Hub class are transient, you can't use them to maintain state from one method call to the next. Each time the server receives a method call from a client, a new instance of your Hub class processes the message. To maintain state through multiple connections and method calls, use some other method such as a database, or a static variable on the Hub class, or a different class that does not derive from Hub. If you persist data in memory, using a method such as a static variable on the Hub class, the data will be lost when the app domain recycles.
Your long running TCP client
This is not a problem with SignalR. Your TCP client can be shutdown by IIS: http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx/
I would rather make the TCP client run in a windows service. The TCP client receives TCP broadcast messages and forwards the messages to the Hub using the SignalR .NET client.
Hubs are recreated on each SignalR request, so if you need a persistent connection you may have to look into using static vars or dictionary to hold state. But as you point ASP.NET can restart for a variety of reasons.
It depends on what persistancy you really need. If you have a connection that MUST stay alive at all times and cannot be torn down and reestablished then hosting in IIS is not the right choice. However, if you can re-establish the same connection after a shutdown, then maybe this can still work.
You can do quite a bit in making sure that ASP.NET apps don't shut down in recent versions of IIS:
http://weblog.west-wind.com/posts/2013/Oct/02/Use-IIS-Application-Initialization-for-keeping-ASPNET-Apps-alive
If that's not enough for you running as a separate service is an option. If you run as a service on the same IP address there are no cross domain concerns. Here's more info on running SignalR using a Windows Service:
http://weblog.west-wind.com/posts/2013/Sep/04/SelfHosting-SignalR-in-a-Windows-Service
I'm developing a webservice that will, when called, notify another program via a tcp connection. My problem is where to store the open tcp connection. The way I understand web services, they start and end with each HTTP Request, with no room for application wide variables, like the open tcp connection.
Please correct me if I'm wrong.
Specifically, in what part of the asmx file, or outside of it, should I place the code for listening for incoming tcp traffic?
Application events in Global.asax should fire for a web service hosted as an application in IIS. You can use these. Keep in mind that they will fire even if a web page and not the web service is accessed in the same application.
You can place the tcp connection as a static member of the service class and make a static constructor that handles the instantiation.
This will create the tcp connection before the first access of the web service is handled and then persist the connection as long as the hosting process is running. The only drawback with that approach is that the tcp connection is process wide. If you host two instances of the web service within the same process (quite unlikely) they will share the same tcp connection.
Fortunately for you, you are wrong.
Application-wide events do fire plus you have the access to all asp.net containers, the Application container for application-level variables, the Session container for session-level variables (if the client side supports cookies, the session id could even be passed in a cookie) and the Items container for request-level variables.
However, whether or not this helps you to store an additional tcp listener (if I understand correcly) is another story, not obvious one.
case 1:
I'm having war in one jboss server and ejb jar in another jboss server.
I want to call my ejb from my servlet which is present in another server.
How to call it. can any one help me with a working sample and required configurations.
case 2:
Message Driven Bean(MDB) in my transaction jboss server and business method in another jboss server. How to call my business method from my transaction server.
kindly help me to solve this case
Thanks in advance
I can't (won't) help with a working example, but this is what you have to do:
Your EJBs (session beans) must be configured in a way to support remote access, RMI.
You have to export your EJB client classes into a separate JAR file; those are the interfaces and base classes required to perform an RMI call (stubs). This is required as clients (your WAR) must understand how to deserialize/serialize the RMI communication between your servlets and the remote EJBs.
Make the exported EJB client JAR available to your WAR file
Define an initial context pointing to your remote EJB server as described here.
Deploy and run it...
BTW: A personal opinion, RMI communication is painful and you should try to avoid it as it tightly couples the client (your WAR) to the remote EJBs.
EDIT: Which EJB version and which IDE do you use?