If CORBA doesn't know about an object at compile time, how does CORBA identify an object passed to it at runtime?
How does it access that object at runtime?
CORBA uses Object References. For inter ORB (the middleware framework code running on your machine) communication, Interoperable Object References - IORs are used. These are string based and contain host, port, policies and other stuff.
You need an objects reference to act with it the CORBA way (location transparent, remote). This reference than is "narrowed" , i.e., the middleware connects to the remote site. After that, every call to the object is a remote call, but you won't notice than in the application as you can handle the object as it where local.
Related
I have a simple question. I'm newer with UnityContainer of Miscrosoft. I'm writing an ASP.NET MVC application with Unity for DI.
Have I a different CONTAINER for each user connected to my web app? Or the CONTAINER is the same for all users?
So if I resolve the life time of an object with ContainerControlledLifetimeManager does it mean that only for one user session this object is always the same?
I hope you understand.
Thanks,
Christian
Lifetime refers to the life of the object created by the DI process. Per request means each request gets its own object. If the object depends on the current user, querystring values on that request or values/presence of Request headers a PerRequest lifetime is appropriate. If you have settings that vary based on location of your service, for example, you saved values from web.config, then a the container is most likely created in global.asa and these objects can live as long as the container lives.
A concrete example:
You have a service as part of your site and you are migrating to vNext of that service. Users can opt-in by clicking a link that includes a parameter like &myService=vNext to see the new behavior. your Factory method uses the value of this parameter to select vNow or vNext for each request.
Here's some pseudo code to get you started:
container.RegisterInstance<IProductFactory>("enterprise", new EnterpriseProductFactory());
container.RegisterInstance<IProductFactory>("retail", new RetailProductFactory());
container.RegisterVersionedServiceFactory<IProductFactorySettings, IProductFactory>();
In this example RegisterVersionedServiceFactory is an extension method that does nothing but decide which of the IProductFactory instances to use for the current request. The factory provides the current instance (there are only two for the life of the service) to use for this request (thousands per seconds).
This pattern is what makes a very large site you probably used recently both very stable and very flexible. New versions of services are rolled out using this exact same pattern to help keep the site very stable.
How do I access my Remote Data Module(RDM)'s instance from another unit at runtime? (The RDM is single instance). When I create a normal Data Module descendant Delphi creates a variable for it in the same unit (ex: MyDM: TMyDM), but when I create a RDM's descendant there's no variable.
I'm trying to set the provider of a TClientDataSet created at runtime in another unit to a TDataSetProvider in my RDM, but I can't find a reference to my RDM's instance.
I also tried to do it at design time but while I have no problems to set the connection property of a TSQLQuery from the same unit to a TSQLConnection in that RDM, I wasn't able to set the TClientDataSet's provider, because no providers from the RDM appears in the TClientDataSet's provider list.
First you need to set the RemoteServer property of your client dataset, assign it an instance of TLocalConnection component (which should be placed on your remote data module since you are not using it remotely). The remote data module unit has to be in the uses clause of the unit with the client dataset, of course.
Then you can assign the ProviderName property of your client dataset.
I did some study on TRemoteDataModule and learned that it is dedicated to support COM application servers.
The fact you don´t have a variable to your RDM is because you are not supposed to access it like a regular DM. The application server will instantiate the RDM in response to a remote call, just like any COM application. It will be destroyed when no more references exist to that RDM.
Since the life-cicle of that object depends on the client, not the server, having a reference to it in the server is highly dangerous. You never know when it´s valid or not. Besides, more than one instance will exist, one for each client that is accessing that object in a given moment.
Considering that, I believe is very reasonable to tell you that it´s impossible to access the RDM after it is created to perform the correction you intend to do.
If you really need to put the TDatasetProvider in a different unit, then my best suggestion is to make the RDM look for that provider in some kind of Provider poll service. Doing like this will enable you to find the provider you need everytime a new RDM is instantiated and only when it is instantiated.
In your place I would add a handler to the OnCreate event of the RDM and in that handler I would call a method like TProviderPool.GetProvider. That method would give me a provider and I would assign its name to the ProviderName property of the CDS.
In a java web app, I need to call a remote soap service, and I'm trying to use a CXF 2.5.0-generated client. The soap service is provided by a particular ERP vendor, and its wsdl is monstrous, thousands of types, dozens of xsd imports, etc. wsdl2java generates the client ok, thanks to the -autoNameResolution flag. But at runtime it retrieves the remote wsdl twice, once when I create the service object, and again when I create a port object.
MyService_Service myService = new MyService_Service(giantWsdlUrl); // fetches giantWsdl
MyService myPort = myService.getMyServicePort(); // fetches giantWsdl again
Why is that? I can understand retrieving it when creating myService, you want to see that it matches the client I'm currently using, or let a runtime wsdl location dictate the endpoint address, etc. But I don't understand why asking for the port would reload everything it just went out on the wire for. Am I missing something?
Since this is in a web application, and I can't be sure that myPort is threadsafe, then I'd have to create a port for each thread, except that's way too slow, 6 to 8 seconds thanks to the monstrous wsdl. Or add my own pooling, create a bunch in advance, and do check-outs and check-ins. Yuck.
For the record, the JaxWsProxyFactoryBean creation route does not ever fetch the wsdl, and that's good for my situation. It still takes a long time on the first create(), then about a quarter second on subsequent create()s, and even that's less than desirable. And I dunno... it sorta feels like I'm under the hood hotwiring the thing rather than turning the key. :)
Well, you have actually answered the question yourself. Each time you invoke service.getPort() the WSDL is loaded from remote site and parsed. JaxWsProxyFactoryBean goes absolutely the same way, but once the proxy is obtained it is re-used for further invocations. That is why the 1st run is slow (because of "warming up"), but subsequent are fast.
And yes, JaxWsProxyFactoryBean is not thread-safe. Pooling client proxies is an option, but unfortunately will eat a lot of memory, as JAX-WS runtime model is not shared among client proxies; synchronization is perhaps better way to follow.
I am developing a J2EE application on Glassfish 3.1 which will use one external library that relies heavily on URLs. The URLs will use a custom protocol (e.g. db:123 where 123 is ID of a record in a database). I am having doubts on how to implement the URL protocol handler (and its URLConnection implementation), because this protocol handler will use EJBs to fetch data from the database.
The db protocol handler needs to be registered globally at the moment of JVM startup through -Djava.protocol.handler.pkgs flag. (I couldn't find a better way to do this in Glassfish.) Anyway, because it is registered at JVM startup, it has no knowledge of any EJBs that that it may call at the moment of opening URL streams. So what I did is create a singleton registry class to which database handlers can be registered. This registry is used by URLConnection whenever a stream is requested (it will search the registry for a database handler and use it to fetch data).
Then, an EJB will register itself as database handler in a #PostConstruct method. This way, any time a db:XXX URL is used, EJBs will be called indirectly to fetch the data.
Somehow I feel that this design is a bit dirty, but I'm very limited because of custom URL handlers. If you have any suggestions or tips that you can give me, that would be great.
My understanding of .Net Remoting is limited (and probably imperfect), so please bear with me.
I've created a service that is hosting a singleton remoted object. It appears that the remoted object doesn't exist until a client attaches to the remoted object. Is this true? If so, how can I create an instance of the object in the service?
Thanks
Paul.
I'm pretty sure that there is no way to do this without calling a method on the object - It's just how server activation works.
You don't indicate why you need to do this, but I'd guess it is because the initialization of the singleton takes a while. Perhaps you could factor off the initialization into another class which is loaded at application startup, and this would reduce the singleon startup costs.
Thanks for you answer!
Actually, I found a way to get what I wanted. The key is that the object that is being hosted for remoting (as a singleton) needs to be a thin wrapper for an actual singleton object (as in Singleton<>). This way the base object will be created no matter what and the remotely hosted object will then be a wrapper for the internal singleton.