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.
Related
I am working testing the auto-scaling feature of OpenStack. In my test set-up, java servlet applications are deployed in tomcat web servers behind a HAproxy load balancer. I aim at stressing testing the application, to see how it scales and the response time using JMeter as the stress tester. However the I observe that HAProxy (or something else) terminates the connection immediately the onComplete signal is sent by one of the member instances. Consequently, the subsequent responses from the remaining servers are reported as failures (timeouts). I have configured the HAProxy server to use a round-robin algorithm with sticky sessions. See attached JMeter results tree , I am not sure of the next step to undertake. The web applications are asyncronous hence my expectation was that the client (HAProxy in this case) should wait until the last thread is submitted before sending the response.
Is there be some issues with my approach or some set up flaws ?
We have developed a TeamViewer-like service where clients connect via SSL to our centralized servers. Other clients can connect to the server as well and we can setup a tunnel through our service to allow peer-to-peer connectivity without NAT or firewall issues.
This works fine with Azure Cloud Services, but we would like to move away from Azure Cloud Services. Service Fabric seems to be the way to go, because it supports ARM and also allows much fine-grained services and make updating parts of the system much more easy.
I know that microservices in Service Fabric can be stateful, but all examples use persistent data as state. In my situation the TCP connection is also part of the state. Is it possible to use TCP with service fabric?
The TCP endpoint should be kept alive on the same instance (for several days), so this makes the entire service fabric model much more difficult.
Sure, you can have users connect to your services over any protocol you want. Your service sounds very stateful to me in the same way that user session state is stateful - you want users to return to the same place where their data is. In your case, that "data" is a TCP connection. But there's no guarantee a TCP endpoint will be kept alive for days in any system - machines fail, software crashes, OSes get patched, etc. You need to be prepared for the connection to break so you can quickly re-establish it. Service Fabric stateful services are great for this. Failover of a stateful service to another machine is extremely fast (milliseconds). Of course, you can't actually replicate a live connection, but you sure can replicate all the metadata you need to re-establish a connection if it breaks.
Does stopping a BizTalk host instance also stop the Applications that run under it?
Or, what is the difference between stopping a host instance and stopping the applications under it?
No, host instances and applications are completely independent. You can stop a host instance and the application will remain in the started state. You can stop an application and the host instance will remain in the running state.
To understand the difference between stopping a host instance and stopping an application you first need to understand what these things are.
Basically, you need to think of your application as a set of assemblies plus some runtime configuration, and a set of logical subscriptions.
When you "start" an application up there are actually two steps which happen.
The parts of your application which need to receive messages (orchestrations and send ports) are enlisted. This ensures that an internal queue exists to receive the messages. Note that the application is not yet started, but it can receive and queue messages for processing later.
Then when you start the application the various parts of your application are able to process the messages.
The host instance is basically a windows service.
When you stop the host instance, all you are really doing is stopping the underlying windows service which runs the host instance. This means that all the assemblies which contain your application artifacts are unloaded, and the application will obviously stop processing. This is despite the fact that the application is still in the started state.
When you start the host instance again it loads your application assemblies back into memory and will be able to continue processing new messages. Messages which were being processed when the host instance was stopped may be in a state called suspended, but if they are can be manually resumed.
Hope this helps.
Yes, if you application run only on that host instance (meaning: application will stop to process messages). However internals of why it stopped processing is quite different. See explanation below and in hugh jadick's answer.
Stopping host instance for specified host type will stop execution of all artifacts (adapter handlers, receive locations, pipelines, orchestrations, etc.) that run on specified host. Application is a logical group of artifacts which can run on single or multiple host instances. Multiple applications can run on a single host instance, and vice versa. So, stopping an app is just shutdown of execution of artifacts, while stopping host instance is shutdown of physical instance there app artifacts are executing.
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.
For a distributed production client-server WCF application (self-hosted as a Windows Service with NetTcpBinding), I am adding logic to add expception to Windows Firewall during the installation via netsh command.
I have noticed that the remote communication seems to work fine whether the firewall exception is for the program (the executable) or port. In our case, the port will very rarely be something other than the default and if it is then user can manually alter config files and firewall accordingly.
My question is, whether it is better to add the exception for program OR port OR both. Are there any security considerations making one approach more desirable than the other? Virtually all of the examples for WCF show port exceptions.
Any insight would be appreciated, thanks.
Here is my summary of how I think they function:
Application exception --> grants the specified application to open any ports
Port exception --> grants any application to open the specified port
As such, which one is better suited depends on the situation. Generally, the application exception would be preferred. At the time an application attempts to open a port, the Windows Firewall (if enabled) essentially would do a check to determine if that application or the port itself has been granted an exception.
MSDN states: "[Application exception] is more secure than opening a port, because the firewall is only open while the program is waiting to receive the connection."
More detailed MSDN summary and technical articles: http://technet.microsoft.com/en-us/network/bb545423.aspx
Ultimately, the system admin for the deployed software should be aware of and/or be the one who makes the changes to the firewall. What we plan on doing is having a step in the installer where the customer can opt-out of the firewall exception but explaining that remote clients will not be able to communicate without it. And of course the manual documentation will also outline the required ports for scenarios if other software or hardware firewalls are in place and need to be manually configured.