For example, java web front can call the Grain method without referencing the Grain Interface based on Grain's interface name and method and parameters?
From Orleans documentation
In order to invoke a grain, a caller must know the grain interface
that the grain class implements that includes the method that the
caller wants to call and the unique identity (key) of the target
grain.
Therefore your grain needs to implement its interface so that it can be addressed through a GrainClient. That if I understand the vague question correctly.
Related
I checked the sample in the Spring4d library on event driven architecture.
From what I can understand, when an event is published, the ServiceLocator will instantiate all classes that implement the IEventHandler<TEventClass> interface and ask these handlers to handle the event.
Though, is there a recommended approach to only ask already instantiated services to handle the event.
Let's say I have an arbitrary number of Controllers that are instanciated. Some of them may be the same class that is instantiated multiple times. Some of them might be unique.
I want these instantiated Controllers to listen to a TUserAdded event. These Controllers implement the IEventHandler<TUserAdded> interface. I don't want the non-instantiated Controllers to listen to the event.
In a way, I would like to get a list of all instances that implement the IEventHandler<TUserAdded> event.
Also, in the ideal case, if a Controller is registered as a Singleton
container.RegisterType<TMySingletonController>.AsSingleton;
I would like to instantiate the TMySingletonController if it is not already instantiated, then, let it handle the event.
Is there a built-in approach in Spring4d to get a list of all instances of a given interface ?
The DI container of Spring4D is a so called non tracking container which means it does not track the lifetimes of the instances it creates (except singleton ones of course).
If you want to resolve all registered services for an interface X then you can resolve TArray<X> or IEnumerable<X> but it will create new instances if they are not registered as singleton.
The sample you looked at was taken from a blog article about combining DI and event driven architecture but your problem more sounds like you need to use the observer and factory patterns. Just please don't abuse the DI container as instance repository.
This may be a silly question, so sorry for asking this, and fyi I'm new to this kind of stuff.
After reading the documentation about mirrors, I can only grasp that the mirrors API is just like copying some instance plus access to some method that I don't know when/why to use.
Anybody care to give me some pointers, some example would be nice.
Mirror API allows you to retrieve metadata about objects and types programmatically (during execution) and to execute methods on objects . It is similar to reflection in .NET or Java.
A typical example is implementing plugin support:
Let's say that you define an IPlugin interface and want to automatically register with your PluginManager an instance of each type that implements it, without need to explicitly register each new implementation. Sometimes you even don't know all the plugins in advance, e.g. if users can deploy their own plugins.
You could do it like this (WARNING: I have never used Mirror API, so this is a high level description based on API documentation, not a proper implementation):
You first use MirrorSystem.libraries to get LibraryMirror instance for each library in that MirrorSystem
Then for each LibraryMirror you use classes property to get ClassMirror for each class in the library
For each ClassMirror use superinterfaces to get all implemented interfaces
If any of the implemented interfaces is IPlugin you can create an instance of that class (ClassMirror.newInstance) and register it with plugin manager.
Without mirror API, you would not be able to enumerate all the types, find what interfaces they implement (without creating an object) or create an instance of a type that you don't know about in advance.
To be honest I am not sure what is the current state of mirror API in Dart, I believe that it is still not finished, but I might be wrong.
I use Web API to return a Contrat EF Entity along with the metadata.
The Contract entity has a PersonId property which holds a foreign key to a Person entity.
That's where things get complicated.
In order to get the Person entity, I need to make a call to a WCF service. This service does not retrieve the entity using entity framekwork. In fact, the Person entity is stored in an Oracle database.
Then on the client side, I need to assign that Person entity to the Contract Entity. I suppose I need to extend the Contract model and add a property of type Person.
I have been through the Edmunds sample, which seems close to what I'm trying to do.
I don't intend to call the WCF service directly from the client. Instead I'm going to make a call to a GetPerson method in my WEB API service, which in turn will make a call to the WCF service.
So, my question is: since I've got access to the Web API service, should I try to return a IQueryable along with metadata (sounds difficult to me), or should I simply return JSON data and go the Edmunds sample's way ?
Which is going to be easier to implement ?
The Edmunds example focuses on client-side queries to HTTP services that you do not control.
In this case, it sounds like you'd prefer to have everything happen on the server that you do control ... including any side-trips to a WCF service. That would be my preference too ... although I don't know the details that are necessary to make that judgment.
If I only need the related Person when I fetch a single Contract, I think I would have my Web API action method return a Contract graph composed entirely on the server (including the Person which I fetched on the server via the WCF Service).
But you may be thinking about the client who needs many Contract entities - each expanded with related Person entities - in a single call. Is this what you mean when you ask about putting IQueryable on the method?
If so, I'd still consider composing these entirely on the server - with side-trips to get the related Person objects - and then perhaps casting the resulting collection as an IQueryable so that the client could filter. Ugh. I suspect that IQueryable isn't wise; IEnumerable is probably better. You can still pass some filtering values to the Web API method (see EntityQuery.withParameters).
Are there any classes (free, open source or commercial) that perform access control similar to what Java's AccessController does? I want to create a dynamic set of policies that can be changed at runtime.
But, I want to avoid having to code
if Allowed( ... ) then
all over the place. I know that I probably need to adjust my program class hierarchy, but I prefer that instead of manually adding guards all over the place.
If there are is no ready-to-use code, what would be a sensible approach? RTTI?
Edit: Here's an example from the Security Annotations and Authorization in GlassFish and the Java EE 5 SDK article. Since somebody mentioned annotations in a comment, I think this would be ideal:
#Stateless
#RolesAllowed("javaee")
public class HelloEJB implements Hello {
#PermitAll
public String hello(String msg) {
return "Hello, " + msg;
}
public String bye(String msg) {
return "Bye, " + msg;
}
}
From the article:
In this example, the hello() method is accessible by everyone, and the bye() method is accessible by users of role javaee.
Edit:
Well, it appears that the general consensus is that this can't be done in Delphi. Others think it is a bad approach.
Me, I still think this would be great. My experience with Annotations in Java (as a code monkey way down in the totem pole) is positive. You add a new method, you add some form of annotation (not exactly the same as Java Security Annotations) and you are done. An administrator can later go to the admin panel and add grant access to this new handler to a group or individual users. It just works.
These are my current alternatives:
The TMS Security System - this appears like a complete solution, with several tools. Worth looking into. I'm accepting this as an answer even if I'm probably not going for it.
This is something that looks promising: Delphi virtual method interception. It only works on virtual methods, but I don't think that's too difficult to comply. This and annotations could make an interesting system (it appears that this was originally designed for DataSnap authentication)
Having only one ActionManager in your application, and make sure that all actions can be only initiated from there. This way you can use the action manager OnExecute method; I pretend to use the TAction.Name property as the permission name ("handler"), reading a list of allowed actions from a table. I can use the action list from the action manager to display the whole list in the admin UI.
There is no such framework for Delphi yet, nor a concept like EJBs that would fit with it. DELPHI does support class annotations, and a framework like this could be designed, perhaps in conjunction with TAction, to provide security on an action level, but I doubt that this could be extended to blocking specific method calls. Delphi code does not ever ask permission to invoke a virtual method. Anything that injected itself into EVERY virtual method call in Delphi, adding a checkPermission call behind the scenes would (in my opinion) be evil. It would be Slow, and worse than writing such checks in by hand.
However, the same techniques that are used to Mock delphi classes could perhaps be used to create some auto-security wrapper object in the future.
I am guessing that the if the Java library in question used Aspects (essentially "injection" implemented via a technique like code-hooking) then it would not require "CheckAllowed" calls everywhere. If you didn't mind changing all your method invocations to implementing an interface, and then providing a wrapper that did the method invocations, and used some kind of auto-generated mock-security-wrapper around it, you could avoid calls to CheckAllowed.
So a guarded No, with a "limited framework possible in future" clause.
Yes, there is a Delphi Access Control Library (lkacl) (OpenSource), JCL (OpenSource) which offers a pretty comprehensive security features, and finally if your demands would be really high the most popular commercial solution is TMS Security System.
In Blackberry Runtime Store, when sharing objects between applications. How can we call methods of the shared object in another application, if the object itself is not recognized in the other application ? i am getting a runtime error when object gets typecasted, as that object is not defined in the calling applicatoin .
If i typecast it to super interface and have the interface in another application. When i call getClass() on the object returned from the runtimestore. It shows as concrete class instance stored in the RunTimeStore.
How can a share a object in runtimestore and use it across different applications ?
The referenced question seems to answer what you're asking.
If you're putting com.foo.bar.MyClass which implements the com.foo.bar.MyInterface in app1, you need to also have it in app2. The package that your class and interface appears to make a difference.
How is your question different?
You seem to have answered your own question - you can typecast to an interface that the calling app is aware of. If you want to cast to a class/interface that's not defined in the calling app though, you're out of luck - it can't be done.
BlackBerry is based on Java ME (formerly J2ME) which has very limited support for runtime reflection - essentially just class names, which you're already seeing when you get the name of the class from the Runtime Store. Unlike Java SE/EE you can't call methods on classes using the String names of the methods - it would be very handy to have sometimes, but unfortunately not supported.
So to summarize, if you can't include the class definition in your calling app, derive an interface (or superclass) with the methods the calling app wants to call, make the class implement that interface, and include that interface/superclass in both the calling app and the other app.