Can ICE be used to create an Open OPC?

It stands for "OLE Process Control", and is a significant part of the Process Control Industry.

The problem is, while it is true that its an open protocal, it is based on DCOM and hense is Microsoft specific.

I know of a user of OPC instruments in the sugar industry that has expressed the opinion that its time for an Open Source OPC solution. Use of Microsoft operating systems in industry is problematic. Specific problems are expense, the fact that they don't stay around long, and viruses.

From what I see of ICE, it looks like it could be the start of a solution of this.

I'd like to solice opinions about this. Expectually if they are knowledgable!

Comments

  • ICE is certainly capable of providing a fast and robust client/server system for process control. An independent standards organization could define a set of standard Slice classes to represent the objects/methods in the process control system.

    If your goal, however, is to avoid having a single company control the specifications of the underlying technology, as Microsoft does with COM, then perhaps ICE is not yet the best choice. ICE is currently only implemented by one company, ZeroC, although I've seen posts from another forum member who is implementing ICE under .NET. It is possible that other implementations may be in the works.

    While posts from the ZeroC founders indicate that they welcome other such implementations, I have not seen any formal statement of this. Also, I don't think there is a well-defined line yet as to what parts of ICE are "specification" (which can be used to write your own version of ICE) and what parts are "implementation" (which are proprietary to ZeroC). For example, can I copy the class interfaces exactly? Or is it only the wire protocol that is open? I think a statement clarifying these issues would be very beneficial for ICE's future.

    There is also no guarantee that ZeroC will evolve ICE in a way that is beneficial to the process control industry (or any particular industry for that matter). No offense is intended to ZeroC in this statement. It simply recognizes that what might be best for ZeroC is not necessarily what is best for others.

    Licensing is also a concern. Although ZeroC generously licenses ICE under the GPL for use in open source software, they do require significant licensing fees for commercial use of ICE. If your goal is a standard that is free of licensing fees, then you'll have to wait until there is a version of ICE with a more commercial-friendly open source license (perhaps like the Apache license). Of course, nobody's stopping you from creating this yourself (I think).

    Once ICE has matured and the standards and licensing issues are more clear, it might be beneficial for an independent group to take over the evolution of ICE. If that were to happen, then ICE would make an excellent basis for many industries to base standards on. Each industry could have representatives join the ICE organization to ensure that their interests are represented.
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Originally posted by Ken Carpenter
    While posts from the ZeroC founders indicate that they welcome other such implementations, I have not seen any formal statement of this. Also, I don't think there is a well-defined line yet as to what parts of ICE are "specification" (which can be used to write your own version of ICE) and what parts are "implementation" (which are proprietary to ZeroC). For example, can I copy the class interfaces exactly? Or is it only the wire protocol that is open? I think a statement clarifying these issues would be very beneficial for ICE's future.

    Nothing in Ice is patented by us, so there is legally no reason whatsoever why somebody couldn't develop a "clone" of Ice, as it happened with many other applications before. Our implementation is copyrighted, and could not be used in such a clone, but of course everybody is free to use our interfaces.
    Originally posted by Ken Carpenter
    There is also no guarantee that ZeroC will evolve ICE in a way that is beneficial to the process control industry (or any particular industry for that matter). No offense is intended to ZeroC in this statement. It simply recognizes that what might be best for ZeroC is not necessarily what is best for others.

    Well, the question is rather, is there anything missing in Ice that is needed by the control industry? Ice can certainly do everything that DCOM can do.
    Originally posted by Ken Carpenter
    Licensing is also a concern. Although ZeroC generously licenses ICE under the GPL for use in open source software, they do require significant licensing fees for commercial use of ICE. If your goal is a standard that is free of licensing fees, then you'll have to wait until there is a version of ICE with a more commercial-friendly open source license (perhaps like the Apache license). Of course, nobody's stopping you from creating this yourself (I think).

    If the goal is to develop an open source process control solution, no special commercial license is needed. Ice is available under GPL, and this allows others to write GPL (or compatible license) applications. Such other applications can be used commercially. This doesn't violate the GPL. Otherwise you couldn't use Linux commercially either.
  • Ken CarpenterKen Carpenter Member ✭✭
    Marc said:
    Nothing in Ice is patented by us, so there is legally no reason whatsoever why somebody couldn't develop a "clone" of Ice, as it happened with many other applications before. Our implementation is copyrighted, and could not be used in such a clone, but of course everybody is free to use our interfaces.
    The potential problem, as I see it, is that your interfaces exist in C++ header files and Ice documentation files that are copyrighted by ZeroC. If it came down to a legal dispute, it would not be hard to claim that another Ice implementation "copied" your interface.

    As I mentioned previously, if your goal is truly to have Ice clones become common, then your documentation should clearly state what is open and what is not. Can I, for example, take an Ice header file, save it, change the copyright, reformat the spacing and braces to my coding standards and call it my own? Probably not. Can I type in basically the exact same thing myself based on reading your header files and documentation? I don't know. Hopefully you see where I am going with this.
    Marc said:
    Well, the question is rather, is there anything missing in Ice that is needed by the control industry? Ice can certainly do everything that DCOM can do.
    Clearly we agree that Ice is more than capable in this regard, so there is no question there.

    The real question is political (or maybe just practical). Can an entire industry take the risk that a small startup company like ZeroC is going to:

    a) be around for a while; and
    b) evolve Ice in a way that is compatible with the industry's needs? (e.g., ZeroC decides to focus Ice on massively multiplayer gaming and changes the APIs and wire protocol to reflect common usage in that area)
    Marc said:
    If the goal is to develop an open source process control solution, no special commercial license is needed. Ice is available under GPL, and this allows others to write GPL (or compatible license) applications. Such other applications can be used commercially. This doesn't violate the GPL. Otherwise you couldn't use Linux commercially either.
    If the company wants to GPL its source code then certainly there is no problem. This is unlikely to be the case for 99% of companies in the process control and automation industries. They guard their source code and binaries jealously and provide all manner of licensing schemes and authentication mechanisms.

    My point in replying to the original message was that there are some very real political and legal issues that need to be understood if you're going to base an industry standard on GPL'd code.

    Maybe you (or someone) could start an "OpenIce" organization to maintain the protocol and interface specifications. Any materials provided by that organization would explicitly state that they are available for any Ice implementor to use. Companies with an interest in Ice could join the organization so that their interests could be fairly represented as changes are proposed.

    Please understand that I think the work you have done on Ice so far is outstanding (and I am VERY fussy about good architecture), but if you want it to eventually replace CORBA and DCOM in popularity, then you'll probably have to "set it free" sooner or later.
  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    Originally posted by Ken Carpenter
    As I mentioned previously, if your goal is truly to have Ice clones become common, then your documentation should clearly state what is open and what is not. Can I, for example, take an Ice header file, save it, change the copyright, reformat the spacing and braces to my coding standards and call it my own? Probably not. Can I type in basically the exact same thing myself based on reading your header files and documentation? I don't know. Hopefully you see where I am going with this.

    Hi Ken,

    I take your point. We may need to clarify this a bit more, I agree. (Right now, it's not really an issue because there is no other implementation but, as you say, this may become an issue in the future.) The spirit of things is that we want to encourage other implementations, and that we'd actively support efforts to create an alternative implementation. As far as copyright is concerned, I suspect we would draw the line if people started to lift our code wholesale and claimed it as their own.

    In practice, I think this means that all Slice definitions that define APIs to the Ice run time would be considered part of the Ice interface, and therefore other people would be free to use those. The same would be true for the Ice protocol, and any language-native APIs that are for use by applications. (There are a few Slice definitions and language-native definitions that exist for Ice-internal purposes--I would consider those part of the implementation, not the Ice interface.)

    I intuitively described the spirit of things with those words--finding a formal definition that would satisfy a lawyer would be quite a bit of work, I'm afraid. For example, copying a header file wholesale would probably constitute a copyright violation if, for example, the private sections of the header define implementation detail so, therefore, copying of the header would imply copying the implementation. In the end, I suspect we'd have to look at such things on a case-by-case basis. (In theory, we could rewrite Ice to strictly separate interface and implementation, for example, using the C++ pimpl idiom to create "private" and "public" header files. But doing so would have a performance impact on the implementation...)
    The real question is political (or maybe just practical). Can an entire industry take the risk that a small startup company like ZeroC is going to:

    a) be around for a while; and
    b) evolve Ice in a way that is compatible with the industry's needs? (e.g., ZeroC decides to focus Ice on massively multiplayer gaming and changes the APIs and wire protocol to reflect common usage in that area)

    Good questions. The way I see it, no amount of standardization (or any other kind of formal process) provides an iron-clad guarantee to a customer. Just think about what has happened to CORBA customers in the past, with vendors going out of business, customer lock-in through proprietary features, and differences in ORBs due to lack of standardization (as is the case for C++ header file names, IDL compiler switches, library names, configuration, implementation repositories, and a host of other things). So, even if we were to formally standardize Ice, this would provide some degree of assurance to customers, but no guarantee. (To give another example, think about what the change from the BOA to the POA did to CORBA customers, and the costs that were associated with that change--just because something is specified by the OMG in no way guarantees that APIs will be stable.)

    Ultimately, any kind of choice of platform for a project entails some risk: the platform may not be supported for the life of the product, a vendor may go out of business, the platform may not be ported to an environment that may be needed in the future, etc. In the end, choosing a particular platform is a matter of faith as much as anything else.

    What Ice has going for it is technical excellence. Our hope is that this excellence will translate into a growing user base (and, so far, things are coming along nicely). The more people use Ice, the safer they are because this creates a base for ZeroC that keeps the company and the platform viable. To put this differently, if you want to feel safer, start using Ice and encourage as many people as you possibly can to do the same--a large user base for Ice is a better guarantee of avoiding platform obsolescence than anything else I can think of.
    Maybe you (or someone) could start an "OpenIce" organization to maintain the protocol and interface specifications. Any materials provided by that organization would explicitly state that they are available for any Ice implementor to use. Companies with an interest in Ice could join the organization so that their interests could be fairly represented as changes are proposed.

    In principle, I agree. Doing this would be useful. But, to be honest, I don't see this as a process that ZeroC should initiate but, rather, as a process that ZeroC should participate in. There is no point in doing all this work unless there are third-party implementations of Ice. And, to be honest, without someone who actually goes through the pain of creating such an implementation, any standardization effort would probably be moot. CORBA is a good example of this: what actually requires standardizing is often not recognized until people go and create real implementations (because that is what uncovers flaws and omissions in the standard). The OMG has spent many years creating standards without implementations, with the result that the specs that are published are often broken, irrelevant, unimplementable, etc. I'd rather not be party to yet another "pie-in-the-sky" standardization process.

    I promise, as soon as someone comes along and creates a third-party implementation of Ice (or of a subset of Ice), I'll be the first person to jump in and help create a standard that actually captures what is needed to ensure interoperability and portability. But we cannot honestly create such a standard out of a vacuum: without the real-life problems that only a third-party implementation can expose, I don't see a way to create a standard that would actually be worth the name...

    Cheers,

    Michi.
  • Ken CarpenterKen Carpenter Member ✭✭
    Hi Michi,

    As always, a very well reasoned response.

    Regarding the API itself, I think you're right that the pimpl idiom is taking it too far. It probably wouldn't be too difficult to automatically extract just the public API from the headers. The extracted files could be designated as starting points for new implementations. I suspect that something like Doxygen could be coaxed into doing this.

    Regarding standardization and guarantees, I don't think anyone expects iron-clad guarantees in today's business climate, but removing obvious sources of risk is still worthwhile. Choosing a platform with a standards body behind it is probably "safer", but as you suggest, the safe way is not always the best way. CORBA is standardized (in its own way), but I believe ICE is superior.

    Regarding your offer of help to create a standard for a third party implementation, I may just hold you to that. ;)


    Ken Carpenter
Sign In or Register to comment.