8tracks - use it!

Well this is not software engineering related, but if you read my blog than you probably aware that I really like good music. Lately I discovered a website that I wasn't aware of before. It goes by the name 8tracks and it's an internet radio.

Yep, I know - there are lots of those lately... Pandora, Last.fm, Grooveshark, Jango, Deezer, Serendip - there are so many more. Some of them free, some of them not.

Those online music services suggest you music to listen to and some of the algorithms that are responsible for that are very interesting. While Pandora, Jango and Grooveshark are based on the resemblance of the music parameters, Last.fm and Serendip based on the social networking approach.

To my opinion, while some of these site provide pretty good playlists for you to listen, they are not focusing enough on the mood of the listener and rely on the assumption that if you listen to a certain music style, you probably would like to listen to songs in the same style over and over again. This assumption is right for, let's say, 85% of the time - "I'm in a mood for some Jazz', you'll say for yourself, "I'll use Jango and ask it to play some good old Brazilian Jazz".

Stan Getz, Bossa nova anyone?

But what about the other 15% of the time when you are interested, for example, to listen to music when you are drinking you morning coffee? You don't care if this is Stan Getz, the Red Hot Chili Peppers or Bob Marley as long as it is in the right mood to fit in the scene of you drinking your morning coffee, right?

The best job, up until I discovered 8tracks, was done by Serendip. Serendip is pretty new in the scene of the online music radio websites. The idea of it is so simple, yet very smart. It connects to your Facebook and Twitter friends and plays the music that your friends shared on their walls. The trick is that this is done almost in real time and therefore the stream consists of tracks that create "the music of now". The music that your friends shared in the morning might fit your morning as well right? The music that you want to hear on a cold winter day, might as well be shared by a friend in the same mood, isn't it?

Nevertheless, what I found so special about 8tracks is that they don't fight for the spot of who has the best algorithm to match the music for your personal taste. It is based on the idea of a simple radio show - meaning that the users themselves create the playlists. The websites provides a very nice and easy to use interface to create a playlist, name it, say a few words about it, and the most important - tag it.

The tag cloud of 8tracks is a vast list of moods, music styles, state of minds and more: "sleep", "love", "workout", "cozy", "party", "rock"... there are so many. One might create a playlist that has a nice acoustic tunes that can fit a gloomy Saturday morning nap, the other can create a playlist that is the best for jogging. This is so simple, yet genius.

Although we are living in the era of technology. Sometimes algorithms, formulas and calculations simply cannot provide what I think is best described by the term "a human touch". Until we would be able to describe a machine what is "a gloomy Saturday morning nap mood" the algorithms based websites will stay on that 85%.

Try 8tracks.com guys.

Gloomy Saturday Morning from emptyskiesabove on 8tracks Radio.

What is DCOM? (Part 2)

After discussing COM and DCOM in the previous posts, I would like to dig into the way DCOM is transmitted over the wire. As I already mentioned, DCOM needs to execute procedures and receive their output via the network. To achieve that it has to use a standard protocol that is implemented on multiple platforms, be security aware and provide a suitable interface that will not harm the advantage of DCOM.

DCE/RPC protocol was chosen for those reasons and it is used as the wire-protocol for DCOM. DCE/RPC stands for Distributed Computing Environment / Remote Procedure Calls and it defines a standard for converting objects and structures into a format that can be split into packets and sent over the network in a platform independent way. Let's dig a little more into details.

The Challenge

It can be said that the goal is set up a "conversation" between a user and the service provider in a way that that the interface that is defined by the service provider could be called by the user from far away, the service provider will process the request and return an answer. When this happens within a local machine, both client and server will usually share the same memory address space so the interface calls, the arguments passed and the return values can be passed and accessed on the process's stack.

When the whole things goes remote and the client and server are not on the same machine/system, the interface calls including the arguments and return values must have a Network Data Representation (NDR) to be sent over the network. The cool thing that RPC mechanism managed to achieve is that it makes the process look to the programmer almost as the interface he uses is just a regular local procedure call. That is why using DCE/RPC was chosen from DCOM.

The IDL

The Interface Definition Language and its compiler. DCE/RPC uses a language to define the procedures, the parameters to these procedures and the data types and objects that the interface will use. An IDL interface will have the following structure:

<interface> ::= <interface_header> { <interface_body> }

For a detailed explanation regarding the definition for the interface header and body, please refer to the DCE/RPC opengroup.org document here.

RPC runtime library

The RPC runtime library is used by both client and server side to implement the communication between them. The runtime library is responsible for finding the server over the network, manage the connection, sending messages, receiving answers, manage and handle errors and more. To keep it simple let's just look at the diagram below.

RPC flow (Source: MSDN)

The client application calls a client stub that is responsible on calling the runtime library interface with the parameter the client application has passed to it. The client RPC runtime library converts the request into a standard NDR and sends the message to the server. The server receives the requests, the runtime library translates it back from NDR into objects and structures that the server understands, queries the server application for and answers and transmits it back to the client.

Every DCE enables machine runs a daemon application called DCE Host Daemon (DCED) and a DCE control program (DCECP) to administrate it. The DCED is listening to the DCE requests and manage them.

DCE/RPC development process

When it comes to the development of a DCE/RPC client/server application the process is pretty straightforward. It comprises of defining the interfaces using DCE IDL, running the IDL compiler to create the client and the server stubs and implement them on the client and server machines.

The IDL interface, like every other interface in computer science, is a set of procedures that the server can execute. On the client side, the client application is linked with the client-stub created by the IDL compiler. The client-stub hides all the network communication with the server. On the server side, the server-stub is linked with the server application, converts the client's calls from NDR and calls the server application that the client requested.

Conclusion

After this discussion I feel that now you should have a pretty good idea what is DCOM, why do we need it and how it works. I didn't go into many details as I think that this blog should be a more-or-less easy read for those of you who want to have a general idea of the subjects that I'm dealing with. Please comment and write me your remarks or requests.

It's a rainy day today so let me finish with a song on that subject. Enjoy!

What is DCOM? (Part 1)

So in the last post I gave you a very brief introduction to what COM actually is. In this post, I'd like to talk about DCOM – Distributed COM.

I won't concentrate on how to write a DCOM program. I will write from a theoretical angle and try to provide a simple explanation of what DCOM actually is. If you are interested in trying some hands-on development, please refer to the excellent article called "DCOM D-Mystified: A DCOM Tutorial" by Brian C Hart on codeproject.com.

So, where were we?

COM objects are self-contained components that can be used in an application and provide a certain service. One can write a COM object and this object can be used via COM APIs. This functionality is extended by the DCOM – Distributed Component Object Model. DCOM allows the COM components to reside on different computers and be accessed by an application from distance.

Imagine complicated software that is using a lot of components to manipulate different tasks and actions – this software doesn't even have to be aware that the components it's using do not reside on the same machine it is running on because DCOM "hides" this headache from the user by providing it "location transparency" that eases the development of distributed applications.

DCOM communicate with distant objects through a remote procedure call protocol that is simply called RPC (maybe more on that in the future posts), handles the "low-level" details of the networking and allows the developer to concentrate solely on his program's functionality.

You can think of DCOM as a mechanism of inter-process communication (this is actually one of the uses of COM), but in a distributed environment. Neither the COM client, nor the COM server should be aware that they do not reside on the same machine and the client's questions as well as the server's answers are carried by the DCOM network protocol back and forth.

DCOM: COM Components on different machines (Source: MSDN)

You can meet DCOM in multiuser network games, chat applications, VoIP applications, network monitoring applications and many more. In the next post I'll dig a little deeper into the guts of the whole process and its exciting features and benefits.

That's all for now. Thanks for reading!


As always I'd like to share with you a tune that I keep listening to on and on during the last week. Enjoy!

A few words about COM

I would really like to talk about Distributed Component Object Model (DCOM) a little, but to do that I first must talk aboutsome basic terms as Managed and Unmanaged code, COM (Component Object Model) andothers. So this post will deal with these terms while in the next post I'lltalk about DCOM and where you can use it.

So let's start at the very beginning.

In the Windows operating system you can write User mode or Kernel mode code. I will write posts about Kernel mode development in the future, but in this one I would like to discuss some basic staff about user space development.

Unmanaged code – a quick reminder

I know that it's probably not agood idea to explain what an unmanaged code is by telling you what is a managed code, but I guess that this would be the easier way to understand it.

Managed code is a Microsoft term for a code that the compilation and execution of which is managed by the CLR - Common Language Runtime. The CLR is an environment that is part of the .NET framework designed to manage the execution of programs. You may think of the CLR as the Java VM because here the code is also compiled to an intermediate language (CIL) that can executed later by the CLR that will convert it into machine code. 

There are numerous benefits that you gain from that. Probably the major one is the memory management that the CLR does for you by releasing objects that are no longer in use (managed data)and operating a Garbage Collector that eliminates memory leaks. But there are other benefits that reduce common programmers' errors. 

In unmanaged code you'll need to manage your own memory allocations, avoid memory leaks and free unused space in the memory. The library/executable that is resulted by the unmanaged code compilation is written in machine code (therefore running faster) and don't need the .NET framework installed.

There are several ways to manage an unmanaged code. One of them is exposing the required methods through COM and use the COM object from the managed code program - this is the most widely used method. A nice article about that can be found here.

BTW, The CLR is implemented as a COM server.

What is COM?

Well, we'll need more than one blog post to deeply understand what COM is, but let's try to keep it simple. For those of you that would like to deepen the understanding and learn how to use COM, I would recommend the "Introduction to COM" article by Michael Dunn in Codeproject.com – an oldie but a goodie.

COM is a standard that lets COM objects to interact with other object enabling sharing binary code across different applications. COM is a binary standard that applies after a program has been translated to binary machine code and specifies that the binary modules (libraries and executables) must be compiled to match a specific structure. 

This is the beauty of it. There is a little that is up to the programmer while the compiler does all the work in creating the COM objects that is easy to use later.

A COM object is made up of a set of data and the functions that manipulate the data. Access to an object's data is achieved exclusively through interface methods. COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface.

COM also defines how objects work together over a distributed environment and has added security features to help provide system and component integrity – but more on that in the next post.

An example – WMI (WindowsManagement Instrumentation)

"WMI provides a uniform interface for any local or remote applications or scripts that obtain management data from a computer system, a network, or an enterprise."

(WMI Architecture,MSDN)

There is lots of cool stuff you can do with WMI and if you're not familiar with it yet, I would recommend toget familiar with it (maybe I'll write a post about WMI too) but let's focus on the fact that the way to use WMI is by its COM interface. The WMI COM API enables developers to write a WMI client or an application that uses WMI information.

Let's take a look at the example from the article "GettingWMI Data from the Local Computer" in the MSDN. First it initialize the COM parameters using the CoInitializeEx() function, then some security information is passed via CoInitializeSecurity() and then we get access to the WMI COM API by using CoCreateInstance() function with the CLSID_WbemLocator object and getting the IWbemLocator pointer.

Now we can call IWbemLocatorobject's function (like ConnectServer()).

HRESULT hres;

hres =  CoInitializeEx(0, COINIT_MULTITHREADED);

    if (FAILED(hres))

    {

        cout << "Failed to initialize COM library. Error code = 0x"

            << hex << hres <<endl;

        return 1;                  // Program has failed.

    }

    hres = CoInitializeSecurity(

        NULL,

        -1,                          // COM authentication

        NULL,                        // Authentication services

        NULL,                        // Reserved

        RPC_C_AUTHN_LEVEL_DEFAULT,   //Default authentication

        RPC_C_IMP_LEVEL_IMPERSONATE, // Default Impersonation 

        NULL,                        //Authentication info

        EOAC_NONE,                   // Additional capabilities

        NULL                         // Reserved

        );

               

    if (FAILED(hres))

    {

        cout << "Failed to initialize security. Error code = 0x"

            << hex << hres <<endl;

        CoUninitialize();

        return 1;                    // Program has failed.

    }

    IWbemLocator *pLoc = NULL;

    hres = CoCreateInstance(

        CLSID_WbemLocator,            

        0,

        CLSCTX_INPROC_SERVER,

        IID_IWbemLocator, (LPVOID *)&pLoc);

    if (FAILED(hres))

    {

        cout << "Failed to create IWbemLocator object."

            << " Err code = 0x"

            << hex << hres <<endl;

        CoUninitialize();

        return 1;                 // Program has failed.

    }

    IWbemServices *pSvc = NULL;

        

    hres = pLoc->ConnectServer(

         _bstr_t(L"ROOT\\CIMV2"), // Object path of WMI namespace

         NULL,                    // User name. NULL = current user

         NULL,                    // User password. NULL = current

         0,                       //Locale. NULL indicates current

         NULL,                    // Security flags.

         0,                       // Authority (for example, Kerberos)

         0,                       // Context object

         &pSvc                    // pointer to IWbemServices proxy

         );

   

    if (FAILED(hres))

    {

        cout << "Could not connect. Error code = 0x"

             << hex << hres<< endl;

        pLoc->Release();    

        CoUninitialize();

        return 1;                //Program has failed.

    }

Nice! Isn't it?

Let's conclude this post with a nice song by Jimi Hendrix, Love or Confusion, because that's how you probably feel right now, isn't it? J

Now in English!

I will continue this blog in English from now on...

While I'm working on my new post, enjoy this tune: