I'm trying to bind my CORBA service to multiple NameServices.
The code is as follows (simplified):
org.omg.CORBA.Object objRef = orb.string_to_object("corbaloc::127.0.0.1:1337,:127.0.0.1:1338/NameService");
NamingContextExt ctx = NamingContextExtHelper.narrow(objRef);
NameComponent path[] = { new NameComponent("toto", "") };
ctx.rebind(path, new MyObject());
VisiBroker 8.5 libraries accept the corbaloc URI, but the service is only bound to the 1337 port.
EDIT: I know that manually binding to multiple NameServices should work, but the corbaloc URI is supposed to do the job.
Any CORBA expert here?
Thank you!
Multi-address corbaloc URIs don't behave the way you'd like them to, unfortunately. The extra addresses are just treated as backups in case of failure. The only one that will be "chosen" will be the first one in the list to respond. Here's some documentation that describes its behavior.
You'll have to manually bind your object reference into each Naming Service, unless your Naming Service implementation supports some kind of replication (I'm not sure if Visibroker's does).
Related
I'm contributing to an open source project that is looking to support multiple containers for its internal services. One of the requirements for supported containers is that order of registration matters. So, if several implementations of an interface are registered in a particular order, when a list of those services is resolved, the implementations should be returned in the same order they were registered.
var builder = new ContainerBuilder();
builder.RegisterType<PreferredService>().As<IService>();
builder.RegisterType<AlternativeService>().As<IService>();
builder.RegisterType<AdditionalService>().As<IService>();
...
// Get the first (preferred) implementation of IService.
var possibleServices = container.Resolve<IEnumerable<IService>>();
IService idealServiceImplementation = possibleServices.FirstOrDefault();
My testing shows that Autofac returns the services is reverse order. Is this always the case? Can I trust they will resolve in reverse order every time? Will this behavior be consistent even if I register some of the later services after other registrations for different interfaces? Can I intercept implicit calls to Resolve for lists?
Is there a way to instruct Autofac that registration order matters?
Autofac registrations are always "last registration wins" unless you use PreserveExistingDefaults(). A quick look into the implementation shows that registrations are stored as a linked list where the default behavior adds to the beginning and PreserveExistingDefaults() adds to the end. Resolving a single service gets you the first item in the list. Resolving enumerable gets you that order. I'm not sure if that behavior is guaranteed to never change.
If it were me, I'd depend on the current behavior, but write an automated test that will fail if the behavior changes.
We have an OpenRasta service, and we'd like to use media types to version our resources. We'll have a different set of DTOs for each new version, distinguishable by namespace. For each version of the DTOs, we have a corresponding media type.
So DTOs will be mapped to media types like this:
Namespace.Dto.V1.MyResource -> application/vnd.Namespace.Dto.V1.MyResource+json
Namespace.Dto.V2.MyResource -> application/vnd.Namespace.Dto.V2.MyResource+json
The repository implementation will be specific to the version of the DTOs, but the interface is generic. I would like my handler and codec to be generic as well, so I don't need to copy/paste them for each version of the DTOs. So I want my routes to look like this:
ResourceSpace.Has.ResourcesOfType<V1.MyResource>()
.AtUri("MyResource/{resourceID}")
.HandledBy<MyResourceHandler<Dto.V1.MyResource>>()
.TranscodedBy<MyResourceCodec<Dto.V1.MyResource>>()
.ForMediaType(mediaTypeMapper.GetMediaType(typeof(Dto.V1.MyResource)));
//V2 of DTOs
ResourceSpace.Has.ResourcesOfType<V2.MyResource>()
.AtUri("MyResource/{resourceID}")
.HandledBy<MyResourceHandler<Dto.V2.MyResource>>()
.TranscodedBy<MyResourceCodec<Dto.V2.MyResource>>()
.ForMediaType(mediaTypeMapper.GetMediaType(typeof(Dto.V2.MyResource)));
Should this work? Right now, it appears that my service is handling requests with MyResourceHandler<Dto.V1.MyResource> regardless of the Accept header on a GET request, for example.
Any thoughts? We could change our scheme to use URIs like /v1/MyResource/ instead of using the accept header, but it would be great to get this working.
EDIT:
I should add that part of the reason we are using media types for versioning is because this is a service for internal use, not meant to be accessible on the public web.
You're registering two resource types on the same URI, only one will get selected, there's no way to do the distinction at request time.
I don't think versioning in URIs or media types is a good idea on the web. That said, for what you want (different mediatypes), then use the same resource type and use your codec to fill-in the same type from the incoming / outgoing data. That's teh responsibility of a codec in OR, making the junction between a DTO and a media type format.
On incoming requests, we need to know what resource type you want based on the URI. If you have two different types it ought to be different resources. that said if you do the following that'll work too:
ResourceSpace.Has.ResourcesNamed("myResource").AtUri("/myResource").HandledBy<ResourceV1Handler>().And.HandledBy<ResourceV2Handler>();
ResourceSpace.Has.ResourcesOfType<MyV1Resource>().WithoutUri.TranscodedBy<V1Codec>();
ResourceSpace.Has.ResourcesOfType<MyV2Resource>().WithoutUri.TranscodedBy<V2Codec>();
you can then write
public class handler {
public object Post(MyV1Resource resource) {}
public object Post(MyV2Resource resource) {}
}
and that'll work. What you won't be able to do is implement the get in that way, as OR assumes one resource type == one URI in most instances.
As for generics, if you use an IoC container, you can register your handlers in a generic fashion (aka register typeof(IHandler<>) with typeof(Handler<>)). This means any IHandler will get resolved to Handler. You can then simply register HandledBy>() in your registration and you're done. Same applies to codecs (but then again, codecs in OR are there to deal with media type issues, not just as serialization mechanisms, as serialization in itself is evil for the web and should be used seldomly).
I wrote a small REST server with the REST datasnap in delphi XE2.
There is a default mapping between HTTP methods (POST, PUT etc.) and the functions defined in delphi, this is done by a delphi component.
This wiki entry describes the URI mapping but also notes that the default mapping can be override by the programmer.
The mapping pattern can be overridden. The user can override the mapping for each type based on class name and method name parameters.
But I didn't find any explanation how to override the mapping.
How can I change the default mapping?
The TDSHTTPService component has events where you can specify the mapping for each type. These events are called RESTMethodNameMapDELETE, RESTMethodNameMapGET, RESTMethodNameMapPOST and RESTMethodNameMapPUT.
This is also explained in the white paper on REST by Marco Cantù, which explains a lot about REST and Datasnap.
I was wondering the same thing, and did some experiments. It seems to be at least partially possible to control the url. Specifically I tried changing the class name part of the url.
Essentially if you are using a TComponent decendant you can name the class anything. This doesn't work if you decend from TDataModule though. In this case you can create and alias class which you can name what you want which decends from your TDataModule.
You need to do some cleanup in the client binding when trying to bind to this, but it seems to work, at least for simple tests.
See more on the Embarcadero forums.
https://forums.embarcadero.com/thread.jspa?threadID=77624&tstart=0
For instance I have this bit of code
public class ProductService{
private IProductDataSource _dataSource = DependencyManager.Get<IProductDataSource>();
public Product Get(int id){
return _dataSource.Select(id);
}
}
I have 2 different data source:
XML file which contains the informations only in 1 language,
a SQL data base which contains the informations in many languages.
So I created 2 implementation for IProductDataSource, for for each kind of datasource.
But how do I send the required language to the SQL data source ?
I add the parameter "language" to the method "IProductDataSource.Select" even if I won't use it in the case of the XML implementation.
Inside the SQL implementation I get the language from a global state ?
I add the language to the constructor of my SQL implementation, but then I won't use my DependencyManager and handle my self the dependency injection.
Maybe my first solution is not good.
The third option is the way to go. Inject the language configuration to your SQL implementation. Also get rid of your DependencyManager ServiceLocator and use constructor injection instead.
If your application needs to work with multiple languages in a single instance I think point one is a sensible approach. If the underlying data does not provide translations for a request language then return null. There is another solution in this scenario. I'm assuming that what you have is a list of products and language translations for each product. Can you refactor your model so that you do not need to specify or asertain the langauge until you reference language specific text? The point being a product is a product regardless of the language you choose to describe it. i.e. one product instance per product, only the product id on the Datasource.Select(..) method and some other abstraction mechanism to deal with accessing the correct text translation.
If however each instance of your application is only concerned with one language set I second Mr Gloor.
First of all I need to point out that you are NOT injecting any dependencies with your example - you are depending on a service locator (DependencyManager) to get them for you. Dependency injection, simply put, is when your classes are unaware of who provides the dependencies, e.g. using a constructor, a setter, a method. As it was already mentioned in the other answers, Service locator is an anti-pattern and should be avoided. The reasons are described in this great article.
Another thing is that the settings you are mentioning, such as language or currency, seem to be localization related and would probably be better dealt with using the built-in mechanisms of your language of choice (e.g. resource files, etc).
Now, having said that, depending on how the rest of your code is structured you have several options to solve this while still using Service locator:
You could have SqlDataSource depend on some ILanguageProvider which pulls the current language from somewhere. However, with more settings like these (or if it is difficult to get current language in an isolated way) this can get messy very fast.
You could depend on IProductDataSourceFactory instead (or, if you are using C#, Func<IProductDataSource>) which would return the concrete implementation with the correct settings. Again, you need to be able to get the current language in an isolated way in order to use this.
You could go with option 1 in your question. This would be a leaky abstraction but would be the simplest to implement.
However, if you decide to get rid of service locator and start using some DI container, the best solution would be using option 3 (as it was already stated) and configuring container accordingly to provide the correct value. Some good ideas of how to do this in an elegant way can be found in the answer to this question
Right now I've got a basic IRepository that takes in IConnect (contains a string value). I'm running into an issue getting my DI (structuremap) to determine which connection string to use. In theory, if I use an attribute on the entity, I could write up a registry/scanner that determines this but I wonder if there's an easier way to do it?
right now I have something like this
ObjectFactory.Initialize(factory =>
{
factory.For<IConnect>().Singleton().Use<ConnectToMarket>()
.Ctor<string>("connectionString")
.Is(_marketConnectionString);
//and some other stuff
});
Ideas?
You could derive different repositories from different interfaces. Say you have a IMarketRepository which is constructed with the market connection string. So all repositories that use the marketconnectionstring are constructed with that connection string (provided you do the registration correctly).
I'm assuming you don't have to use the same repository for multiple connectionstrings?
Another solution could be to make multiple implementations of IConnectionString or something which you can specify in the constructor.
Both solutions are not really nice I must say.