I'm writing some kind of Computing farm with central server giving tasks and nodes that compute them.
I wanted to write it in such way, that nodes don't know what exactly they are computing. They get (from server) an object that implements IComputable iterface, has one method, .compute() that returns IResult type object and send it to the server.
Server is responsible for preparing these object and serving them through .getWork() method on wcf service, and gets the results with .submitResult(IResult result) method.
Problem is, that worker nodes need to know not only the interface, but full object implementation.
I know that Java can serialize method (probably to bytecode) through RMI. Is it possible with c# ?
What you will have to do is put the type which implements the method you are describing into a separate assembly. You can then send the assembly as a byte array to your server, where it will load the assembly, insptect it for types that fit your interface, and then load them. This is the basic pattern for plug-ins using .Net.
Some care has to be taken though. If you are accepting code from arbitrary sources, you will have to lockdown what these loaded assemblies can do (and it is good practice to do even if you trust the source).
A good classic example for how to do this is the Terrarium project. It is a case study that Microsoft produced that involved the viral spreading of arbitrary assemblies in a secure fashion.
You can do
System.Expression.LambdaExpression<Func<result>> lambda = MyFunction;
and then you can serialize expression to string and deserialize on the server
Related
We would like to handle an entire BizTalk message (preferably in the form of an XLANGMessage) through a custom method (.net) that is exposed as a BRE Fact per this article.
Is it possible to define the data being passed to a particular BRE fact as being the entire message? If so, what steps are required to do so (other than defining the method's input parameter as an XLANGMessage)?
EDIT - We simply want to get the entire BizTalk message passed into some custom code so that we can process it - specifically inside the BRE through a vocabulary. The article linked above explains how to set up our custom code to be executed, but I am unable to find out how to set the data being passed to the aforementioned code to be the entire message being processed.
Technically, yes, as XLANGMessage is a .Net class and you can pass instances as Fasts to the Policy.
However, I don't think that would be a good idea. The BRE has it's own Xml Type, TypedXmlDocument, which is used to pass Xml Documents as Facts. This is what happens behind the scene with the Call Rules Shape.
XLANGMessage really just a container, the Part data can take many forms. If it's not XmlDocument, you should probably pass the Part data as it's native underlying Type.
Finally, that MSDN article title is a bit misleading. The BRE doesn't really use Assemblies specifically in any way. What you see there is just a Class Browser. It's the Classes in the Assemblies the BRE can use.
The BizTalk Business Rules Engine Pipeline Framework allows you to call a Business Rules Policy in a pipeline component. As boatseller answered, BizTalk usually wants message to be parsed into an XML format to process and the BRE also deals with XML facts.
(Full disclosure: The BRE Pipeline Framework is written by a colleague of mine at Datacom Systems New Zealand)
I'm trying to find the most efficient way to create an error code list for my web service so that when certain problems occur my client app will know what it is. I don't want to return a lengthy string, so I'd rather use simple numbers. I'm just curious as to how some of you would create your own error code table for an asp.net app. Would you just create a bunch of constants, or an enum type in your web service? Or would you create some kind of class that only holds constants? I'm not sure what the best way to handle this would be. I don't want to instantiate a class just for errors codes every time someone hits the web service.
Edit: I should have been a little more specific. The web service does use data contracts, but doesn't use WCF. I'm using a home brewed implementation of JSON-RPC, which requires that an error code be stored in the response json.
Just a thought for you, but ... don't worry about creating the class, the garbage collector will dispose of it when you no longer need it, and if you use it often enough, then it will stay in the applications memory in Jit form so it will be performant!
Personally, I try to not worry that much about "performance" to the extreme as it is typically not even noticeable...
However, if you are worried, then you should look at creating a single static class which can be used application wide and instantiated on start up and hold the constants there as then a single in memory class will be used saving on memory and any perceived performance hit.
Best wishes
Matthew
Assuming you mean the WCF type of web services, you can use FaultContract to specify different errors and how to handle them on the client side.
You are not programming in C, why error codes?
Web service is broad here but I assume you mean WCF?
Anyway WCF throws a FaultException which bubbles up to the client and this is a lot better than using error codes. Error codes don't tell me anything, and can be prove to be a PITA to maintain later.
But if a FaultException occurs there are lots of information that I can glean from the object.
FaultException (or SomeException) > Error Code.
I'm new in web services and I'm developing a C# WCF service that is calling an external service from another company to get some client data (for example: name, address, phone, etc), this part is working fine so far.
The external service is based on a standard XML Schema, and other companies will have soon the same service generated from the same XML Schema, using the same name methods and returning the same type of xml file.
My first question is that after I complete this first implementation, there is any way to add “dynamically” the other external companies services, having the information of their URL/Ports/etc, or do I have to insert each on them manually as services reference in my internal service project every time I need to add a new one, then compile and re-deploy?
My second question is related with the data contract /members, my understanding is that even if they are returning the same XML files, their data contracts/members will be different, is that true? So I’ll have to make a specific code to read the information I need from their data contracts for each new external company?? If this is true I have been thinking to make a generic code to read the raw xml, is this the best choice?
While C# is a compiled language it does support pluggin architecture through MEF. You could use this and add a small plugin .dll for each of your sources.
That being said it's quite possible that all you need is a configuration list containing connection details for each of your sources and connecting to them dynamically. That will only work if they're using the exact same schema, so that the objects they serve will serialize the same for all sources. You will have to instantiate the proxy dynamically through code using that configuration then, of course.
I should add something for your second question. As long as you're the one defining the contract, it doesn't matter if their actual objects are different. All you care about on your end is the xml they serve, and that you can connect using your representation. In fact, you can generate the contract as a .wsdl document. Each of the service-implementer can then generate domain objects from that. On the other hand if you're not the one "owning" the contract, some of the sources may decide to do it slightly differently, which will cause you a headache. Hopefully that's not your scenario though.
Best of luck! :)
My first question is that after I complete this first implementation, there is any way to add “dynamically” the other external companies services, having the information of their URL/Ports/etc
Unfortunately yes, you will have add service, compile it and deploy every time
My second question is related with the data contract /members, my understanding is that even if they are returning the same XML files, their data contracts/members will be different, is that true?
If you will use auto generated every service will create different contracts. I would think about creating you own class and convert external classes using reflection and extension methods
I have a desktop C# app that I want to split into two parts - server part and client part. My app is already split into two very independent parts that communicate by exchanging some (complex!) objects.
If I want to put one part of my app on some web server, what kind of technology should I use for passing those custom complex objects between the server part and client part? I was thinking about WCF, but...I'm not sure that WCF can easily handle (send/receive) custom objects (composed by many other custom objects). I don't need WCF because I'm not planning to offer my service to any third-party, I'm not planning to port my client app to other OS...
That's why I'm confused and need your help: what kind of remoting technology should I use in my case?
WCF stands for Windows Communication Foundation. In other words its about general cross process/machine communication and not limited to hetrogenous systems
One thing to remember about WCF is, despite appearances, you are not actually passing objects at all - the objects are used by a serializer to generate messages.At the other end it will deserialize into an independent copy. You don't, unlike COM, get a reference back to an object on the sender.
The reason this is important is because if the complex objects have non-serializable state such as a socket connection then this won't make it to the receiver side
Also, with the DataContractSerializer (which is the default) unless your objects are annotated with the [Serializable] attribute or you annotate the classes with [DataContract] and [DataMember] you will only be sending state that is exposed publicly (via a public field or a property).
This isn't purely a problem for WCF; Remoting requires objects derive from MarshalByRefObject or are annotated with the [Serializable] attribute. Building distributed systems is quite different from building systems that all share the same memory address space. You have to think carefully how you define that boundary between the distributed pieces because, for example, lots of small calls will kill your performance rather than few data rich calls (although from your description this might not be an issue that affects you)
So WCF can handle arbitrarily complex object graphs but just remember the above points about serialization
Well, DataContracts in WCF support complex objects, so I don't see a problem with that (how complex are your objects); however you should probably use the technology that is sufficient in your case. You can use Remoting, hell, even Sockets; but it is in almost all cases overkill and going too low in .NET stack for nothing; you will just be wasting your time in implementation.
If you have no reason against WCF, I would go that way, because it is very simple and powerful. There are also standard ASP.NET ASMX web services if you'd like.
One thing to note, whichever the technology, you should have your code structured in a distribution layer, exposing coarse-grained methods.
I serialize some configuration objects and store the result bytes within a database.
new BinaryFormatter().Serialize(memoryStream, instance);
Convert.ToBase64String(memoryStream.ToArray());
These objects will be deserialized later.
new BinaryFormatter().Deserialize(memoryStream);
It's possible, that the Application has some new assembly versions at the time of deserialization. In general it works well, but sometimes I get a file load exception:
"The located assembly's manifest definition does not match the assembly reference.". The assemblies work all with strong naming, can that be the problem and how could I avoid this problem?
Thanks for help
Absolutely, using BinaryFormatter with database (i.e. long-term) storage is a bad idea; BinaryFormatter has two three big faults (by default):
it includes type metadata (shucks if you move/rename your types... this can mean strong name/versioning too)
it includes field names (fields are private details!)
it is .NET specific (which is a pain if you ever want to use anything else)
My blog post here raises two specific issues with this - obfuscation and automatically implemented properties... I won't repeat the text here, but you may find it interesting.
I recommend the use of a contract based serialization. XmlSerializer or DataContractSerializer would suffice normally. If you want small efficient binary, then protobuf-net might be of interest. Unlike BinaryFormatter, the binary from this is portable between implementations, extensible (for new fields), etc. And it is quicker and smaller, too.
I think WCF might be your best bet. It can handle passing unknown fields through to it's consumer even if it doesn't know how to deserialize them.
Example:
Service A: Knows about version 2 of the Widget class which has a Description field
Service B: Knows about version 1 of the Widget class which doesn't have a Description field
Service C: Knows about version 2 of the Widget class which has a Description field
If service A calls service B passing a Widget object and then service B calls service C passing on the same Widget object then service C will get the Description field as it was passed from service A. Service B won't have any Description field but when it deserializes it and re-serializes it it will just pass the Description field through without knowing what it is.
So, you could use WCF services with in-proc communication.
See this link for more on versioning wcf contracts.