This question is a follow up on a previous asked question: link
I have to develop a Windows Service in .NET/C#. The service must be consumed by an application written in VB6. The service implements Quartz.NET to handle scheduled tasks and must implement listeners to be able to start functions that are initiated by the VB6 application.
The requirement for the VB6 team is to be able to use Winsock. Therefor I have to use sockets and listeners. The problem is that I have no experience with that, I'm more of a WCF guy.
I'm looking at the TcpListener class now to see if this will fit the requirement.
My first question: Will the VB6 team be able to consume the service if I implement the TcpListener class, keeping in mind the short comings of using VB6 (such as data structures and binary formatting)?
My second question: Let's say 3 functions must be available for the VB6 application, and 1 listener is created. What are the best practices for the implementation of this?
Once again: any advice is much appreciated!
Passing payloads as XML, textual Key/Value pairs, JSON, or other loose serialization formats can help future-proof your protocol. This allows you to use and even add new optional method arguments to the server end at will.
In addition to a "method" field you can have a "protocol version" field. When a breaking change is made (new required args, changes in existing arg types, etc.) you can use the version number to handle both old and new clients during a transition period - which might span years.
As far as providing message framing on top of the TCP stream goes you can use simple EOM delimiters of some sort or a message header containing a binary or text length prefix.
You might also consider Named Pipes. TransactNamedPipe() is fairly easy to call from a VB6 program. This takes care of the message-boundary issue for you - assuming you want an RPC-style protocol rather than async send/receive.
Or you might go all the way and use MSMQ. Private machine queues don't require extensive administration. But even though both VB6 and .Net have excellent MSMQ support most devs know little about it.
Related
I am considering replacing a .NET WFC duplex endpoint with gRPC. Like most frameworks, WCF allows for the data to just be simple contract objects so what you use over the wire is what you can use in your processing code (if you are ok with that coupling). But with gRPC and GPB, it looks like I can't do that and I have 2 options. One is to translate my existing .NET objects on both ends of the communication, which will add extra labor/complexity. The other is to use the protocol buffer messages verbatim in business code, which couples business code to transport technology.
So my question is .. what is the best solution to use gRPC and avoid translation or direct use of buffers in business code?
Both can be valid options: copy or use directly.
In larger/deeper systems it's good to translate to some "internal" objects that can have more fields and morph to the system without breaking clients. Those "internal" objects could even be protobuf messages. In this case, the duplication is a feature.
In smaller/shallow systems it's easy to directly use the protocol buffers without copying. You should realize that one day you may need to convert to some other version of the protos or make some sort of POJO or similar. But it's also possible that day never comes.
So the question isn't really, "Is it okay to use protocol buffers in business code," as that easily has few issues. But really the question is, "Is it worthwhile to allow the system internals to develop separately from its API?"
I have been trying to do some reading on how to communicate best, and it appears that the way to communicate between non-related processes running code in different languages is usually through the use of "named pipes."
it seems like in C# you would normally use WCF while setting some bindings to make use of named pipes. However, in C++, should i just directly create a named pipe or is there some framework/library that I should use to create named pipes?
Also, what alternative options do I have to create events in C++ that a C# application can hear?
There are a number of IPC mechanisms to choose from in Windows.
Having evaluated a number of them, its really a case of deciding which one has the least disadvantages for your use case. I've used named pipes for a C# to C++ messaging system, and I'm still not sure I made the right choice.
That said, if you are just looking at signalling events (and don't need to include state) a shared mutex might be a lightweight alternative.
EDIT: I meant to say that if you do choose named pipes you'll need to use a custom solution. Using WCF would mean reverse engineering the WCF messaging format and reimplementing it in C++.
I have two applications: one in C#, the other in Java. I need a way to transfer data from the C# application in XML format to the Java application using some kind of service.
I have only worked with sockets before, but am looking for something less proprietary for future use with other applications. What other alternatives are there?
*Please note that the extent of my knowledge with working with sockets was a simple client/server written in java.
If both programs run on the same machine, you could of course also use files, but in general, this is how it goes down:
Create a webservice in C#, implementing a method that exposes your data.
Use the wsimport tool provided with the jdk, point it at the above created .wsdl file to generate java classes to use as a soap client.
Use generated classes to consume webservice.
(I see now you insist on XML. So forget about it)
These are completely distinct issues - it's like asking if I want to speak with you now, should we have a phone call in French or maybe mail correspondence in Mandarin. So it's:
Means of transferring data (S.A HTTP, or TCP, or whatever).
Some common structure of data.
Confusingly, both are regarded as 'protocols'.
Anyhow I'd say protobuf over HTTP is the most obvious and straight forward thing to use.
I want to separate modules of my program to communicate with each other. They could be on the same computer, but possibly on different ones.
I was considering 2 methods:
create a class with all details. Send it of to the communication layer. This one serializes it, sends it, the other side deserializes it back to the class and than handles it further.
Create a hashtable (key/value thing). Put all data in it. Send it of to the communicationlayer etc etc
So it boils down to hashtable vs class.
If I think 'loosely coupled', I favor hashtable. It's easy to have one module updated, include new extra params in the hastable, without updating the other side.
Then again with a class I get compile-time type checking, instead of runtime.
Has anyone tackled this previously and has suggestions about this?
Thanks!
edit:
I've awarded points to the answer which was most relevant to my original question, although it isn't the one which was upvoted the most
It sounds like you simply want to incorporate some IPC (Inter-Process Communication) into your system.
The best way of accomplishing this in .NET (3.0 onwards) is with the Windows Communication Foundation (WCF) - a generic framework developed by Microsoft for communication between programs in various different manners (transports) on a common basis.
Although I suspect you will probably want to use named pipes for the purposes of efficiency and robustness, there are a number of other transports available such as TCP and HTTP (see this MSDN article), not to mention a variety of serialisation formats from binary to XML to JSON.
One tends to hit this kind of problem in distributed systems design. It surfaces in Web Service (the WSDL defining the paramers and return types) Messaging systems where the formats of messages might be XML or some other well-defined format. The problem of controlling the coupling of client and server remains in all cases.
What happens with your hash table? Suppose your request contains "NAME" and "PHONE-NUMBER", and suddenly you realise that you need to differentiate "LANDLINE-NUMBER" and "CELL-NUMBER". If you just change the hash table entries to use new values, then your server needs changing at the same time. Suppose at this point you don't just have one client and one server, but are perhaps dealing with some kind of exchange or broker systems, many clients implemented by many teams, many servers implemented by many teams. Asking all of them to upgrade to a new message format at the same time is quite an undertaking.
Hence we tend to seek back-comptible solutions such as additive change, we preserve "PHONE-NUMBER" and add the new fields. The server now tolerates messages containg either old or new format.
Different distribution technologies have different in-built degrees of toleration for back-compatibility. When dealing with serialized classes can you deal with old and new versions? When dealing with WSDL, will the message parsers tolerate additive change.
I would follow the following though process:
1). Will you have a simple relationship between client and server, for example do you code and control both, are free to dictate their release cycles. If "no", then favour flexibility, use hash tables or XML.
2). Even if you are in control look at how easily your serialization framework supports versioning. It's likely that a strongly typed, serialized class interface will be easier to work with, providing you have a clear picture of what it's going to take to make a change to the interface.
You can use Sockets, Remoting, or WCF, eash has pros and cons.
But if the performance is not crucial you can use WCF and serialize and deserialize your classes, and for maximum performance I recommend sockets
What ever happened to the built in support for Remoting?
http://msdn.microsoft.com/en-us/library/aa185916.aspx
It works on TCP/IP or IPC if you want. Its quicker than WCF, and is pretty transparent to your code.
In our experience using WCF extensively over the last few years with various bindings we found WCF not be worth the hassle.
It is just to complicated to correctly use WCF including handling errors on channels correctly while retaining good performance (we gave up on high performance with wcf early on).
For authenticated client scenarios we switched to http rest (without wcf) and do json/protobuf payloading.
For high-speed non-authenticated scenarios (or at least non-kerberos authenticated scenarios) we are using zeromq and protobuf now.
We are building a system that interacts with an external system over TCP/IP using the FIX Protocol. I've used WCF to communicate from client to server, where I had control over both client and server, but never to an external TCP/IP based system. Is this possible with WCF? If so, could the community provide links for me to get started and faced in the right direction?
Unfortunately I do not have much more information that what is supplied above, as we are still in the early early planning stages. What we know is that we have an external vendor whose system will communicate with our system over TCP/IP. We would like to use this as a learning opportunity and learn WCF.
Possible? Possibly yes, but it's going to take some work.
For starters, you will need to write a custom WCF Transport Channel that handles the specifics of your TCP/IP based protocols (i.e. you'll need to write all the socket handling code and hook that into the WCF channel model). This is because the TCP channel in WCF isn't for this kind of work, but uses a relatively proprietary and undocumented wire protocol.
I'm not familiar enough with FIX to say how complex it would be, but there are some gotchas when writing WCF channels and documentation in that area isn't great.
The second part you'll need to deal with is message encoding. To WCF, all messages are XML. That is, once a message is passed on to the WCF stack, it has to look like an XML infoset at runtime. FIX doesn't use XML (afaik), so you'll need to adapt it a bit.
There are two ways you can go around it:
The easy way: Assume the server/client will use a specific interface and format for the data, and have your channel do all the hard work of translating the FIX messages to/from that format. The simplest example of this would be to have your WCF code use a simple service contract with one method taking a string and then just encapsulating the FIX message string into the XML format that satisfies the data contract serializer for that contract. The user code would still need to deal with decoding the FIX format later, though.
Do all the hard work in a custom WCF MessageEncoder. It's a bit more complex, but potentially cleaner and more reusable (and you could do more complex things like better streaming and so on).
The big question though is whether this is worth it. What is your reasoning for wanting to use WCF for this? Leveraging the programming model? I think that's an important consideration, but also keep in mind that the abstractions that WCF provides come at a price. In particular, some aspects of WCF can be problematic if you have very real-time requirements, which I understand is common in the kind of financial environment you're looking at.
If that's the case, it may very well be that you'd be better served by skipping WCF and sticking a little closer to the metal. You'll need to do the socket work anyway, so that's something to consider there.
Hope this helps :)
I don't think it is possible, at least it won't be easy to set it up because you don't know the communication protocol of the other end, except for it's TCP and accept FIX tags.
Why don't you within WCF application open TCP connection a SOCKET. That should do the trick in a simpler manner.
I think so. I have a system that I almost got working that was supposed to do almost exactly that (WCF over HTTP from the internet). The server provider seemed to not want to allow it thought so you will need the right permissions on that end to make it work.
Up shot: I don't see why not.
Not really - Ms didn't make the TCP/IP connection handler to talk to non-WCF services, they assumed you'd write a Web Service to do that.
This is discussed here on SO.