SolidWorks As A Service – Part 4

Here are links to Part 1, Part 2 and Part 3.

In this part, I would like to talk about another issue that affects me and my company directly – third party add-ins.

SolidWorks prides itself on its very successful partner program, of which SYCODE has been a part of for many years. I dread the day when SolidWorks as a Service becomes a reality because when it does, I am not sure what will become of the numerous third party add-ins developed by SolidWorks partners as well as those developed in-house by users themselves.

I believe most users are not aware of how add-ins work because they are usually wrapped up in a neat installer. For the benefit of those who are not aware, let me explain what actually happens. A developer creates an add-in (basically a DLL) which is copied to the end user’s computer by the installer. The installer also registers the add-in with the SolidWorks installation on the end user’s computer by adding certain information to the registry. The installer also copies supporting DLLs and other files that the add-in needs at run-time.

When everything is set up the user goes ahead and invokes a command added by the add-in by clicking on a menu item or toolbar icon which was added by the add-in during it own startup. Now in the case of SolidWorks as a Service, SolidWorks is installed on the server, or rather on all the servers on the server farm. The user does  not get to pick the server that he wants to run his SolidWorks off. So this means that exactly the same version of each and every add-in created by each and every developer must be installed and registered on each and every server on the server farm.

While this is logistically idiotic but theoretically possible, it throws the concept of third party add-in licensing into the shit pit. At SYCODE, we tie the license for all our SolidWorks add-ins to the user’s network card or MAC address. Other developers tie their licenses to the hard disk ID or some other fixed parameter or combination of parameters that uniquely identifies a computer. I have absolutely no idea how to control the licensing of my add-ins on a server farm. I guess add-in developers would have to piggy back on the licensing mechanism employed by SolidWorks.

And what about add-ins developed in-house by users? They would need to be installed and registered on each and every server on the farm as well, with SolidWorks somehow making them invisible to everyone else.

One way of solving this problem is by having add-ins installed only on some servers and keeping a track of which servers have which add-ins. Whenever a user invokes a command from an add-in, control can be passed to that server which will then execute the command in the add-in on the user’s data. But this brings up a chicken and egg situation because the user interface to invoke an add-in is added by the add-in itself. However, in reality none of this even matters because the user interface for an add-in would need to be added to the user’s browser window or whatever the hell that the user is using to run SolidWorks off a server. Basically, this whole concept of having add-ins run off SolidWorks installations which in turn run off servers on a server farm gets convoluted to the point of stupidity. And hence I call SolidWorks as a Service an idea which is completely nuts.

And speaking of passing control, here is some more food for thought. When you pass control from the SolidWorks instance on one server to the SolidWorks instance of another server, you need to remember that along with control you also need to pass the data that needs to be worked upon, basically the 3D models and the recipe that is used to cook them up from scratch (the history based feature tree) along with all related information like materials, etc. To get an idea of how much data that is, try loading a large assembly and watch your computer grind to a halt. Passing control between servers is not as easy as flipping a switch on one and flipping it off on another.

Like I said, completely nuts.