I have read somewhere that I better use multi-part types on receive and send ports, but can't understand one thing. If I receive some XML data through say HTTP port how do I put it in right path in the message. Should I create custom pipeline for this or there is something else (I'm new to BizTalk)?
Sergej,
You must have picked up this concept half baked from the article 8 Tips and Tricks for BizTalk Programming (http://msdn.microsoft.com/en-us/magazine/cc163423.aspx)
As explained in the article, it makes more sense to create Multi-Part messages inside the orchestrations, so when you want to change something in the schema its easy to do so without deleting all the links between the ports and send/receive shapes.
Assigning a message to a specific part (normally the first part) should not be a big issue within the orchestration, you should be able to do it via maps or within the message assignment shape.
HTH
There's really no hard and fast rule about using multi-part message types for something like this; it really depends a lot on your scenario.
However, I'd like to point out that, underneath, all messages in BizTalk are, at the lowest level, multi-part messages. The question is whether accessing those extra parts (if they are present) is easy in an orchestration or not ;)
That said, let me point out that, in many cases, there's little reason to use multi-part message types in orchestrations. For example, the HTTP or FILE adapters will never generate a message with multiple parts on their own, unless perhaps you've got something like the SMIME decoding component on your receive pipeline.
Some other adapters do definitely take advantage of multi-part message types, like perhaps the POP adapter (attachments) or the SOAP adapter. But unless you've got an scenario like this, that really requires multi-part message types, I see little reason why you'd start with those.
Related
I'm trying to create a system that will be very modular. with the idea in mind that no module should really know about any other module (each running in it's own process).
There will be another program that will open, and will be able to tell what these modules will send and receive(this I largely have covered).
the issue I'm having at the moment, is there a way for me to be able to interrogate the application inside another process, or app domain? and in so doing late bind these modules together.
EG:
A module that can broadcast 'X' at runtime will be liked to a module that can accept 'X'.
This may be quite vague, and if so please ask me to clarify on anything I have not covered.
Right now, I Just need to know if it is possible to interrogate a process, and if so how? I Am fairly new to this but my initial research hasn't taken me to far.
I modeled a system like this recently for a personal home automation system. Basically, I'd want to be able to have certain sensors (microphones, cameras, etc.) broadcast what they have, and have other computers or programs get that information whenever they need it, without knowing exactly who is going to be getting the data at compile time.
If this sounds like what you're looking for, I'd look into a Pub-Sub style architecture.
http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
You're not really interrogating the process in this kind of architecture, but I think you get a similar result. Basically, you'll have one main pub-sub server.
In the Diagram above, Clients 2 and 3 "subscribe" to receive a specific kind of message. The server knows who is subscribed to what, so that when Client 1 sends that message, the server knows it needs to route it to the correct clients.
I hope this helps.
EDIT: After re-reading your question, I feel that you may have already gotten this far. Maybe all you need is something like
http://msdn.microsoft.com/en-us/library/bb546102(v=vs.110).aspx
Pipes allow you to pass some information between processes. You'll have to serialize and de-serialize the data across the pipe, but this (coupled with a pub-sub architecture) should give you what you need.
I've just made a quick research about that but there is nothing about that in C#.
Is this a lost cause or it can be made?
As Yahoo Messenger is not an open source project, I have no idea about how sending message is implemented. First thing you should do is launching Wireshark on your machine to see how Yahoo Messenger works (which port is used, which protocol, data encryption...etc.).
When you have determined how the application works, you'll have to write some low level code that intercepts and modifies the bytes Yahoo Messenger sends. You'll probably have to write a driver, so it looks to me like a dead-end if your are using C#. And even using C/C++ or any langage usable to write drivers, it'll require a large amount of time/resources IMO.
You are trying to modify behavior of an closed source application. The only thing i can think of is somehow goeing lower-level in the OSI model (Transport layer i.e.) and change values. This sounds like a bad idea.
Actually i even wonder whether that data is sent plain-text or that encryption etc. has been used. I wonder if you can actually change the message at all.
I want to do a project, that will include server and clients sides, using TcpSocket network communication (I use TcpListener for server and TcpClient for client side) and threading. But threading is not giving me any problems so far any longer.
But what it does, is something else... because the project will not include only chat, (but also creating new game, joining game, making moves, leaving game), I need to define somehow the message format.
I have read about messaging protocols and about using first few bytes of each message to tell the server what they are trying to do. The problem is that I do NOT know how to do it. So can someone show me an example of creating formated message?
Maybe its good to mention I use StreamReader and StreamWriter classes to pass data between server and clients. Is this a good way?
To add:
My problem now, is how to seperate this data, so that the server will know what to do with it. I have read about using 1nd few bytes to "be reserved" for the type of the message. But the problem is I don't know how to solve this issue. So far I was only using StreamReader and StreamWriter classes to pass only strings. If I use these kind of coding, it will all become too messy (not recognizable), if you know what I mean.
So I need to do something like it:
To send bytes:
1st few bytes the type of the data (but I don't know which class to use, maybe a BinaryWriter, and BinaryReader on the other side??)
the rest of the message
on server I have to have some code that will recognize these "1st few bytes" so the code will know what to do with the test of the message.
and based on these "1st few bytes" the code has to send data back to clients
Do you have any ideas on what this might look like, I mean as a skeleton (something basic, so I can work on with it).
Every bit of help would be very much appreciated.
I have found one example here on stackOverflow.com. It seems to be a code into a right direction. What do you think guys?
One option that might be much easier than defining your own protocol would be to use some existing library, like WCF or JSON-RPC.
Libraries like this have their disadvantages (they often produce output that is relatively big). If if you build your applications in a modular way, you can easily switch the communication backend later, when you find your first solution wasn't good enough.
You have a few options:
Make the message format textual - including its header. So, the header contains the message size, written out as text string, and ends with some terminator (\r\n for example.) HTTP takes this approach - the headers are text. When receiving the message, you process it with ReadLine, and parse header lines with stuff like int.TryParse(str).
Send message:
output.WriteLine(message.Length);
output.Write(message);
Receive message:
int len = int.Parse(input.ReadLine());
//message is the next 'len' characters
A second option: entire message is in a binary format - the message header is binary, and specifies amongst other things the message length. Message content is written as a stream of bytes, encoded using for example Encoding.UTF8.GetBytes(str).
Or, perhaps use the HTTP protocol? I believe there is basic support for HTTP server in the form of HttpListener. Here is a simple intro to HttpListener
Whatever you do, avoid using WCF :)
I am thinking of making a server/client application that does this: the client(s) will connect to the server and the server will send back a list of folders (probably music or videos) that the client will be able to stream or download. I am going to make a GUI for this so that it won't be a text-only interface. I want it so that when the client connects to the server and gets the information about the media files that can be streamed/downloaded, the client will show the folders/files in an explorer-like interface (folders will show up with a folder icon, videos will show up with a video icon, etc.)
This seems really big to me but I really want to learn more about socket programming with C# and feel that getting my hands really dirty is the best way. As you can imagine, I have a lot of confusion about how to start this and what it is that I need to do to make this work.
The first part of my question is: If I want to let a client receive a list of files/folders and also have the ability to download/stream them, do I need to do something with transferring binary data using sockets or am I completely wrong on that? If I'm wrong, do I need to use something else like file readers and somehow use them over sockets?
The second part to my question is: when I transfer this information over to a client, how can I make the client show the appropriate icons for videos, folders, mp3s, etc.? I'm thinking that if I have to transfer binary data I will have to use that data to somehow populate the client GUI with the correct icons/data. I am stuck on exactly how to handle that. Are there certain methods/classes that I can use to parse that data and do what I want to do with it? Again, I don't know if I'm wrong about needing to transfer binary data but either way I am confused on what it is that's necessary to handle this.
I apologize if any of my terminology is wrong. I am obviously not an expert in C# yet ;)
Any time you are sending data between machines (or between processes), you are already talking binary data (you could argue that everything is binary data, but when working with it as an OO model it doesn't feel like it). The point here is that all you need to do is serialize your messages. There are a myriad of serialization frameworks - some aimed at convenience, some aimed to range-of-features, and som can use aimed at performance (minimum bandwidth etc).
Even the inbuilt ones would work - for example, you can use XmlSerializer etc to write to a Stream (such as the NetworkStream you typically use with a socket). But please - not BinaryFormatter (it will hurt you, honest). Personally I'd use something a bit less verbose such as protobuf-net, but I'm somewhat biased since I wrote it ;p
However, note that when working with sockets, you are typically sending multiple (separate) messages as part of the conversation. In order for each end to correctly and conveniently read the right data per-message from the stream, it is common to prefix each message with the length (number of bytes) - for example, as a little-endian int taking a fixed 4 bytes. So the reading process is:
read 4 bytes
interpret that as an int, let's say n
read n bytes
run that data through your deserializer, perhaps via MemoryStream
process the message
and the sending process might be:
serialize the message, perhaps to a MemoryStream
query the length and form the 4 byte prefix
write the prefix
write the data
You don't have to go to as low level as Socket, unless you just want to learn of course.
I suggest using WCF. It will completely meet your requirements, will be flexible and you will not have to deal with sockets directly.
WCF is a big framework, but you can quickly learn how to use it.
Introduction to WCF
Here you can find how to retrieve and show file icon in Windows.
If you client is hosted by Windows, you don't need to transfer icons, you can just retrieve image on the client by filename/extension.
I have built two programs in C# and I am sending simple strings through the sockets. This is fine for the moment but in the near future I will need to send more complicated items, such as objects down the sockets and eventually files.
What steps would I take to do this? What purpose do the buffers serve for the sockets/streams? Apologies if I am a little vague.
If you are sending objects, you have to really be careful with what you do and how you are planning on using those objects on the other end. All properties need to be serialized. If you are going to have large amounts of data in theses objects, you may want to use binary serialization instead.
Also, look at the guidelines posted here: MSDN Serialization Guidelines
If you are going to be sending objects, you may want to look at either .Net Remoting options or WCF Services if applicable. Rolling your own socket handlers and then using it for complex operations is asking for a lot of time and pain, especially if you haven't done it before.
There are many options, but basically you want to serialise the data into a format that will go through the socket.
Worth looking here into xml serialisation.
One way you can handle this is to serialize your object into XML, send over the socket, then deserialize it. I've done it this way before. However, I (being fairly new to .NET) just learned about the JavaScriptSerializer, which I believe makes this process a lot easier for you.
You need to serialize the objects.. Mark it with [Serializable] attribute and use some serializers.. Example can be found here.
First thing in any comms situation is to consider that anything you send must be able to get serialised and de serialised so that it can get over a comms channel. Next you must consider that comms have latency (its not instantaneous), and then the fact that it can fail.
After this you consider the protocols and technology to enable the above to be factored in.