Control standards and initiatives, was ALL: An (open) announcement

  • Thread starter Matthew da Silva
  • Start date
M

Thread Starter

Matthew da Silva

Original-From: Anthony Kerstens <[email protected]>

>With TCP/IP and Java, Linux has already looked after connection
>to Microsoft Windows apps. A great many web servers are run
>off Linux boxes. :)

You're correct, and I'm not as knowledgable about this as a lot of the posters, but what about ActiveX? I read Moore-S' response and Curt's response to Mr. Moore but there's the rub. Curt even goes so far as to recent and say, at this mature stage in the discussion, that he'd be happy for Windows to be the platform of choice, were that it could fulfil an aspired goal of true openness.

While all this discussion of what platform to use is useful, we're also trying to figure out the best way to implement control in the plant (I'm from the process side of the industry) and not just process control, but equipment lifecycle control, also. In the batch arena, you've got the SP 88 standard for process control which seems to have been gotten nailed down with (relative) ease. But on the continuous, exothermic, process side you've got fieldbus and something called PI STEP. Does anybody have a better knowledge, than me, of PISTEP? Web site says: " [PISTEP] aims to increase the competiveness of UK companies in the process industries by improving engineering information management throughout the lifecycle and the supply chain. "

The part that really interests me (since I'm in sales and marketing) is this program item:
" International standards for representing information -- both the data and its meaning -- as a basis for exchange and sharing. "

This sounds real similar to what's happening in the CALS initiative, but mainly in the U.S. Now, furthermore, parts and systems procurement improvement would, logically, relate intimately with engineering execution improvement, because for the automation of either, requires a set of standard terminology that comprises referents of things, and those referents are unique for the entire system, and all participants use the identical referents.

E-commerce needs the same foundation, to get into motion. In discrete automation sectors, I think, automotive companies are backing standardization. It is also likely that, that situation, will
mature faster than its equal in the process side.

Hope this isn't too far off-topic, to get a response. Moderator, you may need to give this post a new title. Your choice.

<OK, this is the start of a new thread, see subject line. --Jennifer Powell>

Regards,
Matthew, Yamatake
 
C

Curt Wuollet

Hi

Yes, to hear them talk, manufactureres are intensely interested in standards. The whole problem in a nutshell is that they are not at all interested in _one_ standard or in each others standards. That's why we have dozens of "standards" and no standard. As far as initiatives, we could use a lot more followers and
a lot fewer "Leaders". Imagine if every site on the Internet decided they simply had to have their own standard. It would work like systems integration in this industry.

Curt Wuollet
Wide Open Technologies
 
Anthony:

What's up with Active X/COM is the basis for OPC. OPC is fast becoming the standard interface between conventional computers and controls.

Sam
 
C

Curt Wuollet

What about them? They are easy and provide remarkable connectivity as long as you're married to Microsoft and Microsoft only. Aye, and _that's_ the rub.

ActiveX/COM and OPC are the latest schemes to inhibit interoperability and promote a Microsoft only world in perpetuity. Far better to use cross-platform schemes and include Microsoft. You might soon run across a customer who is not enamored with the Windows Everywhere dogma. Even the most virulent Redmond cultists could agree that it doesn't hurt to hedge your bets. With java development becoming prevalent in Corporate IS, single vendor solutions may be an albatross before they are obsolete. A small amount of foresight has almost no downside and could be of enormous value in a rapidly changing world. I know of many developers who wish already that they had been more inclusive in their strategy. Besides, it doesn't hurt to take a proactive stance in avoiding the proprietary traps and pitfalls that plague this industry. No one
will criticize you for not marching in lock-step with Bill Gates. Follow that path and you will find yourself locked-in yet again. I am reminded of Deming's definition of insanity. That's where you keep doing things the same way and expect the results to be somehow different.

Regards

Curt Wuollet,
WOT
 
R
Curt Wuollet wrote:

> ActiveX/COM and OPC are the latest schemes to inhibit interoperability and
> promote a Microsoft only world in perpetuity.

You can't blame them, they will do what their customers will let them get away with, let the buyer beware.

The basic problem as I see it is that the automation industry in general has little experience of networking and integrating on a large scale, there is no systems experience. As such they cannot be aware of the pitfalls, they
have yet to fall into them, and they will not start doing so for another 2 or 3 years yet. By that time they will be so deeply entrenched in thier erroneous ways that it will be too difficult to get out, and what should have been
great fun for all will become a thorn in the side.

Microsoft do actively support Open Protocols and standards that are considered superior to thier ActiveX/COM and OPC offerings, they just don't shout about it, and I do not blame them. The more unwise users they can lock in the better from a business viewpoint. No wonder they are pushing COM/DCOM so heavily in automation.

On the other hand the Open alternatives will always be there in full force, as some market sectors have far more experience than automation, and insist on Proven Open technology, they would rather not use the OS than base their network operations on closed code that is controlled by a single company. Automation would be wise to bury their pride and adopt techniques used by market sectors with more experience, and bigger systems than themselves.

Specificaly I am thinking of the telecommunications industry, network systems engineering is thier core business and believe me their supervision and remote diagnostics are second to none. With 625Mbit multiplexers being shoehorned into holes under the sidewalks, and GSM repeaters being lifted by helicopters onto high peaks (not to mention the satcomms sector), they need to be.

Telecoms have for several years been making the transistion from thier traditional RPC based systems (very reliable and easy to implement, but design time defined) to a more dynamic system based on the Open Corba standard. Telecomms are not alone. Banking, governement institutions, Military.....just about any serious major user distributed information systems....are taking the CORBA route. Microsoft may not like it, but to not fully support these standards would mean excluding themselves from the most serious, and wealthiest, market sectors (Telcomms, Banks,
Governments and Military are about the only things that are bigger and richer than MS;-) ).

But automators are very proud, I have mentioned CORBA before, as well as open standards, on the list, and I have been flamed for my pains. I have even been accused of being a communist. Go and tell it to AT&T...............

> No one will criticize you for not marching
> in lock-step with Bill Gates.

Rubbish. You can waste hours sorting out problems with MS technology, and evereybody sympathises with you...... but block a system for half an hour with a non MS solution and everbody is saying why didn't you use........

It's like IBM of 20 years ago.......

I must confess howerver, this is one of my best liked features of windows, nobody blames you when your software throws up obscure messages, it's kind of like they expect it to happen.....
 
P

Phil Covington

Roger,

CORBA is not a solution to everything just because it is "open". It is very big, complicated, and error prone compared to COM. ORB incompatibility is a big problem... COM is an open and freely available specification. It
consumes the least amount of resources of any present object model.

Of course, Microsoft's implementation of COM has some Window's dependencies. I am glad to see a few efforts by individuals to implement COM on Linux. But I have a feeling that COM is rejected so strongly by Linux advocates because it is Microsoft's idea...

A notable item is that the University of Utah has based their OSKit interfaces on COM. The OSKit is a set of modularized components and library
code for the construction of operating system kernels, servers, and OS level functionality. It is at http://www.cs.utah.edu/flux/oskit/

Interesting that they are able to make use of COM and their OSKit has nothing to do with Microsoft.

Regards,

Phil
 
R
> CORBA is not a solution to everything just because it is "open". It is very
> big, complicated, and error prone compared to COM. ORB incompatibility is
> a big problem... COM is an open and freely available specification. It
> consumes the least amount of resources of any present object model.

My citation of CORBA over COM is that I see what people have done with CORBA, and what they have not done with COM, at least at a WAN level. COM is local integration with networking added on. CORBA is WAN level integration that is heavy at a local level.

I think your appraisal is a bit exaggerated. Obviously when you are talking about something with wide capabilities, it has more parameters, can appear more complicated, and that inevitably leads to more teething troubles. But if you are aiming for a certain level in the long term, it is better to start slowly in order to make great leaps and bounds later rather than start quickly with something that runs out of steam later.

BUT, I am a bystander here, I have never personally implemented a large system with either COM or CORBA, my opinions are based on
observation. In fact I have observed the KDE folk abandon CORBA for local interprocess apps, but I have also seen the very large systems that the telecoms folk do with CORBA.

My gut feeling is derived from network experience. Once upon a time TCP/IP was too big for PC's, and so we used lighter LAN protocols.
The mostly widely diffused was of course NOVELL, whose IPX was a simplified IP, and used a client server approach as opposed to peer to lighten client overhead. Nowdays TCP/IP is no problem for the PC, and so we use it as single standard, WAN, LAN and even local. So I feel that while network enabled interprocess communications have a role in life, in the long term we are headed for something bigger, at least as far as interoperability on a large scale is concerned.


> Of course, Microsoft's implementation of COM has some Window's dependencies.

Or put another way, COM is an open standard, but write COM objects to the standard and they do not necessarily interoperate. It's fieldbus all over again. Never had interoperability problems with centronics, or ethernet, or TCP/IP (well, not many). Open standards where people do actually comply to a free set of rules do exist, and work, and survive the test of time. CORBA, as you correctly point out, does have some interoperability problems, not least because (like COM) there are allways people wanting to drag it along thier own lines. But the core of CORBA are wotking towards interoperability, wheras COM, to all intents and purposes, just waits until MS changes it's mind or adds some showstopping 'feature' and adjusts all it's code to accomodate. My head starts spinning when I just look at all the catchy names they have invented.

I can say my XYZ language conforms to open standards because it uses the ASCII character set. The palm pilot has windows compatible
software. The problem is not COM, it is what people are doing in automation with COM is not open, and MS can render the whole lot obsolete at a whim (or to make you adopt a upgraded system). MS have a long reputation for doing this, it is naive to 'trust them', and certinaly not a sound business decision.

> I am glad to see a few efforts by individuals to implement COM on Linux.
> But I have a feeling that COM is rejected so strongly by Linux advocates
> because it is Microsoft's idea...

Oh I imagine that is true. But a lot of Linux advocates are not actually Linux users, and certinly developers are not like that. True
Linuxers tend to be happy to use the best solution, the whole point of Linux is you are free to choose what method you use. In fact the
Linux community has open heartedly adopted the SMB protocoll for file serving over the UNIX NFS standard, as it is more adapted to modern networks than the NFS system that was designed for interconnecting at a server level. (BTW, I know SMB was an IBM protocoll, but the last 10 years it has been MS who have plugged it).

I am not anti MS, I am MS weary. I thought OS/2 was good, and when MS were telling us that we should do all are development for that instead of windows because it was the future, I believed them. Then they dropped it, left IBM to pick up the pieces, and competed directly against it.I remeber my first Windows compiler. MS had launched the 32 bit extensions to Win32 and I was happy in the knowledge that my development kit would be able to produce applications that whould be able to run on the upcoming Win95, NT etc. etc. Like as hell.

> A notable item is that the University of Utah has based their OSKit
> interfaces on COM. The OSKit is a set of modularized components and library
> code for the construction of operating system kernels, servers, and OS level
> functionality. It is at http://www.cs.utah.edu/flux/oskit/
>
> Interesting that they are able to make use of COM and their OSKit has
> nothing to do with Microsoft.

So their COM objects are interworkable with VB COM objects, and visa versa? The point is that it is not enougth to call something a standard, or just call it by the same name, there has to be at least a DESIRE to make thinks interoperate, and not rely on proprietry extensions. Tomorrow, the goal posts move, and you can no longer buy a license for the OS with the old extensions.
Upgrade...re-write....modify.

At the end of the day the Automation objects being so heavily prompoted on this list will only work with particular versions of a very
proprietry OS. They are also based on an evolving protocol that has to go some way before it reaches the level of solutions that have been deployed for some time. Did you see what the Olivetti/Oracle research labs were doing in Cambridge 5 years ago?

By contrast, in LISA times people on the automation list might have been interfacing a PC to a Siemens S5 using ProDave with DDE, a COM
predecessor. Many new machines are still being built with the S5, but you cannot legally buy a PC to run the software, as THAT DDE only runs with WIN3.1, and MS will not sell you a license. You cannot compile in the support yourself. That protocoll will no longer be sold. Go-rewrite.

Likewise the Automation objects people are so keenly developing today will not run on the systems of tomorrow.

Sure, I am cynacal. But I have been kicked in the b***s many times. When it is the same person doing most of the kicking, claiming that it is in your best interests, it is difficult to like them.

I think CORBA may be over the top for Automation requirements, but I would rather spend time on something heavy yet reliable than on something that can dissapear (or mutate) and leave me in the cold.

Perhaps the people pushing COM should do more to ensure that thier objects are not OS dependent, and insist on the ability to install the protocol into the OS rather than have it built in.

Does anybody know anything better than both COM and CORBA;-)
 
J
I am by no means a network expert, administrator, etc., but reading this thread reminded me of a conversation I recently had about something called
"Jini". I had no idea what this was and did a little research to find out that it is a Sun Microsystems product. Due to my lack of expertise and knowledge in this particular area, I was wondering if some of the listers could comment on this and how it would all tie in to this particular thread.

I found more information on Jini at http://www.sun.com/jini/

Thank you,
Jeff Shiepe
Nestle USA
Project Engineer
 
M

Mattias Wallinius

Hello roger,
Have a look at Java. Java is a more complete model than COM or CORBA that only solves a part of your problem when programming for distributed
environments. One of the beauties of Java is that you can map the distribution to either CORBA/IIOP COM/DCOM or to Java RMI which is Javas own
protocol. SOAP is also about this with interoperability as you use XML over HTTP to
bridge the distribution model. Using the right UUID and you can call from a COM object to a CORBA object over the Web. This is why it's important and also non Microsoft way of doing things! This is also why DevelopMentor has
done a lot of work porting SOAP. http://www.develop.com/soap/ . I think that
there must be a more moderate way of looking at things. COM is good and so is CORBA. Each has it's own strengths and weaknesses, but COM is dominating due to installed base. Also OPC is increasingly more important in the Automation industry so why don't embrace it instead. It's the best so far. Let's map OPC interfaces to
CORBA and to Java RMI so that the dependencies of Microsoft decreases. Let's implement COM/OPC on Linux, already done by a german company, VxWorks
already has there own version. If many enough does this Microsoft will have the customers against them when changing the technology. Actaully COM is very much tied down as there are to many non Microsoft applications out there that will break if they change the model to much. The problem as I see it is that there is a lot of poeple that don't understand COM or CORBA and
that languages like VB hides some "important" details from the developer leading to bad implementations.

/Mattias Wallinius, Sr System Engineer
Tetra Pak Converting Technologies AB
Ruben Rausings gata
S-221 86 Lund, Sweden
email: [email protected]
phone:+4646361248
fax: +4646362504
 
M

Mattias Wallinius

COM and CORBA and Java RMI are all different flavors of the same thing. They provide what is called component object models. Component are objects that can live in differnt processes from each other and still talk to each other. The whole idea behind this is that you separate the interface of the object from the implementation. COM is about this done on a binary level and CORBA
on a interface level. The big differens is that COM was originally done for process on the same machine while CORBA always has been about cross
networking and cross platform. So in short words it's all about distributed applications and getting past the limitations of the original object orientation in C++ and Smalltalk. Java is a bit funny here it can map to CORBA or COM but also has its own model for the same called Java RMI.

/Mattias Wallinius, Sr System Engineer
Tetra Pak Converting Technologies AB
Ruben Rausings gata
S-221 86 Lund, Sweden
email: [email protected]
phone:+4646361248
fax: +4646362504
 
Just an application comment - I'm not a Java expert, but we have a customer who is using a Java applet to create Modbus/TCP polls to networked Modbus resources. They complained about it taking 830 or 940 msec for the applet to send each poll & receive the request on a PREVIOUSLY opened socket. I did some timing tests and was able to confirm that our Modbus/TCP to Modbus/RTU
bridge worked in from 80 to 125 msec (complete from MB/TCP receipt to RTU poll/reply at 9600 baud to MB/TCP reply) so that extra 700+ msec lag was from the brower's Java Machine. By the way, their applet is stored & served from our bridge, so that gets them around the security issue of opening sockets in Java. This timing was done on a isolated single-hub system so network delays are negilable.

This is of course an "implementation issue" - no doubt faster Java or Corba environments exist, but when most people think of "Java", they think of something which runs under Netscape or iExplorer and not some custom, optimized run-time environmant.

regards

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132
 
A

Armin Steinhoff

>Roger,
>
>CORBA is not a solution to everything just because it is "open".

It is designed for real distributed systems ... not for local interprocess communication.

> It is very big,

Well ...here are big and very small implementations in the field. Lots of the free implementations are really small .. ORBIT, omniORB, ILU, MICO

>complicated, and error prone compared to COM.

I'm not convinced ... IMHO a clean implementation for a UNIX system work more reliable than any Windows based implementations.

> ORB incompatibility is a big problem... COM is an open and freely available specification.

COM isn't open because it is still controlled by one single company.

> It consumes the least amount of resources of any present object model.
>
>Of course, Microsoft's implementation of COM has some Window's dependencies.

It is completely Windows based ... especially the part for the local communication.

>I am glad to see a few efforts by individuals to implement COM on Linux.

I know only about a single one. SAP/DEC for LINUX ... it's years ago.

>But I have a feeling that COM is rejected so strongly by Linux advocates
>because it is Microsoft's idea...

There are other good technical reasons in field not to use COM ... e.g. it is not fully object oriented.

>A notable item is that the University of Utah has based their OSKit
>interfaces on COM.

It's also noteable that COM is used here only as one of many interfaces ... just for component oriented inter process communication.

>The OSKit is a set of modularized components and library
>code for the construction of operating system kernels, servers, and OS level
>functionality. It is at http//www.cs.utah.edu/flux/oskit/

[ clip ...]

Regards

Armin Steinhoff
 
P

Phil Covington

From: "Armin Steinhoff" <[email protected]>

> I'm not convienced ... IMHO a clean implementation for a UNIX system work
> more reliable
> than any Windows based implementations.

What evidence do you have that Windows based implementations are not reliable? My first hand experience says that you are wrong...

> COM isn't open because it is still controlled by one single company.

Again, you are in error. COM is open...

> > It consumes the least amount of resources of any present object model.
> >
> >Of course, Microsoft's implementation of COM has some Window's
dependencies.
>
> It is completely Windows based ... especially the part for the local
> communication.
>
> >I am glad to see a few efforts by individuals to implement COM on Linux.
>
> I know only about a single one. SAP/DEC for LINUX ... it's years ago.

This statement makes me question your credibility. You should do some more research. I know of at least two current projects for Linux. If you are interested I will point you to them...

> >But I have a feeling that COM is rejected so strongly by Linux advocates
> >because it is Microsoft's idea...
>
> There are other good technical reasons in field not to use COM ... e.g. it
> is not fully object oriented.

How do you justify that statement? Not fully object oriented? Ha!

> >A notable item is that the University of Utah has based their OSKit
> >interfaces on COM.
>
> It's also noteable that COM is used here only as one of many interfaces
...
> just for component oriented inter process communication.

If COM is so useless, then why do they use it at all in their OSKit?

Funny how you are so down on COM... You are in the minority though. A lot of good software and reusable components are built with/on COM.

Regards,

Phil Covington
 
W

Wallinius Mattias

Java can have bad peformance and the earlier versions had. Applets one should be careful with anyhow because badly written they have bad
performance and also are not easy to move from one platform to another.
/Mattias
 
At 09:12 PM 4/14/2000 -0400, you wrote:
>----- Original Message -----
>From: "Armin Steinhoff" <[email protected]>
>
>> I'm not convienced ... IMHO a clean implementation for a UNIX system work
>> more reliable
>> than any Windows based implementations.
>
>What evidence do you have that Windows based implementations are not
>reliable? My first hand experience says that you are wrong...

I have two types of experience with Windows reliability. I have had a few systems that are totally reliable, as far as I know. Those were NT systems that were not networked and dedicated to a single task. I also have experienced numerous desktop systems with all sorts of strange problems. I would like to think that WinNT/2000 would be rock solid, but I cannot be
sure. It has already blue screened on my home system.

With Unix, the reliability has been proven on large servers for years. There are zillions of Linux boxes out there with long uptimes.

Here is the question that was recently posed to me. Our system should not have a software failure, even once a year. Blue screens and lockups will be unacceptable. Which OS should we use?

I would rather not use QNX, due to its cost and the fact that is somewhat "closed", at least from a users viewpoint. WinNT/2000 is a possibility,
but I not that confident of it's reliability. That leaves Linux, which is reported to be very reliable. My experience with Linux is that is very solid. Therefore, I think that I should choose linux.

Bill Sturm
 
A

Armin Steinhoff

At 21:12 14.04.00 -0400, Phil Covington wrote:
>----- Original Message -----
>From: "Armin Steinhoff" <[email protected]>
>
>> I'm not convienced ... IMHO a clean implementation for a UNIX system work
>> more reliable than any Windows based implementations.
>
>What evidence do you have that Windows based implementations are not
>reliable?

IMHO the basic concept of the Win32 API doesn't allow reliable applications. For instance ... please have a look to the calls for interprocess
communication.

> My first hand experience says that you are wrong...

My first hand experiences show me how unreliable that stuff can be ... day by day.

>> COM isn't open because it is still controlled by one single company.
>
>Again, you are in error. COM is open...

So you mean the COM specification is not a property of Microsoft ?? Are you sure that you will never pay licenses to MS if you have built a
commercial product based on COM ??

[ clip .. ]
>> >I am glad to see a few efforts by individuals to implement COM on Linux.
>>
>> I know only about a single one. SAP/DEC for LINUX ... it's years ago.

Sorry ... they have implemented DCOM. So I don't really know any single plain COM implementation besides the OSKit.

>This statement makes me question your credibility. You should do some more
>research. I know of at least two current projects for Linux. If you are
>interested I will point you to them...

I'm interested ... please let us know!

>> >But I have a feeling that COM is rejected so strongly by Linux advocates
>> >because it is Microsoft's idea...
>>
>> There are other good technical reasons in field not to use COM ... e.g. it
>> is not fully object oriented.
>
>How do you justify that statement? Not fully object oriented? Ha!

E.g. there isn't supported INHERITANCE for the COM interface. Inheritance is THE core of any true object orientation!

>> >A notable item is that the University of Utah has based their OSKit
>> >interfaces on COM.
>>
>> It's also noteable that COM is used here only as one of many interfaces
>> just for component oriented inter process communication.
>
>If COM is so useless, then why do they use it at all in their OSKit?

I didn't say it is useless ... I said that the OSKit is not BASED on COM. Let's draw here the right picture.

>Funny how you are so down on COM...

I'm not down on COM ... I see just lots of conceptual weaknesses of COM.

>You are in the minority though.

I feel comfortable with the minority of more than 800 companies which are supporting CORBA as OMG members ... and I feel fine with the minority of users of JAVA :)

Regards

Armin Steinhoff

http://www.steinhoff.de
 
E

Edelhard Becker

Hi together,

i think i have to add my $0.02 here ..

On Fri, Apr 14, 2000 at 09:12:43PM -0400, Phil Covington wrote:
> ----- Original Message -----
> From: "Armin Steinhoff" <[email protected]>
>
> > I'm not convienced ... IMHO a clean implementation for a UNIX
> > system work more reliable than any Windows based implementations.
>
> What evidence do you have that Windows based implementations are not
> reliable? My first hand experience says that you are wrong...

don't know where you got your experience, but i never found a reliable Windows machine. In contrary: which family of Operating Systems is
famous for its "Blue Screen of Death"? And which one for running large scale servers?

Windows (including 2000) is _by_design_ a Desktop-OS for Personal Computers, which means: switch the PC on, do some calculations in Excel, write a letter, print it and switch the PC off again. Unix is a multi-user, multi-tasking OS, which means: run the OS endlessly and serve as many users and as many processes as the system allows
(depending on CPU power and memory size). Therefore it has a completely different design.

At the University, we had SGI IRIX, HP-UX and Linux Systems and all of them run day and night for months without rebooting (usually until the
building's electricians test the power system and simply shut off the mains :-/

> > COM isn't open because it is still controlled by one single company.
>
> Again, you are in error. COM is open...

So, where can i get the final spec, i'd be interested. Everything i found so far is the document COM_Spec.ps (in the archive COM1598C.ZIP
on Microsofts [D]COM webpages). It's dated from October 24th, 1995 with version 0.9 with a Note: "This document is an early release of the final specification. It is meant to specify and accompany software that is still in development. Some of the information in this documentation may be inaccurate or may not be an accurate
representation of the functionality of the final specification or software."

But anyhow, COM is only for IPC on a single machine, and therefore of interest only for Windows Developers (using COM for IPC on a UNIX
machine does not make any sense). The larger problem for the connectivity is DCOM, because it _should_ insure interoperability between distributed systems. According to [1] (from Nov. 1996), "COM and DCOM are no longer proprietary to Microsoft, but are managed by the independent ActiveX Consortium". The latest news on their webpage is from December 1996, most of the links point directly to Microsoft pages. This group seems to be very active.

DCOM is very tightly coupled to Windows' memory layout and the object format of the Visual C++ compiler [3,4]. Internally there are complex
manipulations with pointers into the Visual C++ vtable. This complexity is hidden from the developer by Libraries (ATL) and macros. But Microsoft can change this _implementation_ at any time [4]. By adding the changes to the ATL and the macros, DCOM with Visual C++ will work as before, but not implementations on other platforms.
(BTW: this mixing of OS, proprietary techniques, development environment and applications only for getting rid of their
competitors exactly is the subject of the Anti Trust process against MS.)

There exists not even a formal description (e.g. in BNF) of Microsofts IDL for COM [4], so when is an COM IDL file syntactically correct? The only way is to check with Microsofts IDL compiler.

The latest DCOM spec i found was an Internet-Draft [2] from 1998 ("Expires in six months").

> > [..]
> > There are other good technical reasons in field not to use COM ...
> > e.g. it is not fully object oriented.
>
> How do you justify that statement? Not fully object oriented? Ha!

- DCOM IDL does not support exceptions [3,4].
- All DCOM methods must return HRESULT (a 32 bit integer), nothing different, especially no arbitrary object [3].
- The programmer must manually take care of the server's reference counting (AddRef() and Release()) [3,4]
- COM does not support multiple inheritence [4]
- For object persistence, the client has to know the server's storage media, the path to the location etc. [4] (or it uses MTS, a completely proprietary Microsoft Service)
- The only possibility for code re-use (one of the fundamental advantages of OO programming) in the COM IDL is aggregation, but every member function of the included class which is needed by the application again has to be explicitely declared [3]

Would you call that object oriented?

> [..]
> Funny how you are so down on COM... You are in the minority though.
> A lot of good software and reusable components are built with/on COM.

Because COM is such a poor technique, it does not prevent many companies to invest much time, money and other efforts into it to get some usable (maybe even good) software. Microsoft is the leading force in the market ("leading" by means of marketing and market share, not technology, visionary developments or software quality --- IMHO we all agree on that). By including COM, DCOM, ActiveX, OLE, VBA etc. etc. into their development environment, they make it very easy for programmers to start off without the need to evaluate other techniques, tools etc. But the IT world is not, and will never be, a streamlined, Windows-only world, so every programmer should prefer truly open, interoperable standards.

> Regards,
>
> Phil Covington

Greetings,
Edelhard

References:
-----------
[1] http://msdn.microsoft.com/library/backgrnd/html/msdn_dcomtec.htm
[2] http://msdn.microsoft.com/library/specs/distributedcomponentobjectmodelprotocoldcom10.htm
[3] http://www1.bell-labs.com/user/emerald/dcom_corba/Paper.html
[4] http://www.quoininc.com/quoininc/COM_CORBA.html
--
s o f t w a r e m a n u f a k t u r --- [email protected] URL: http://www.software-manufaktur.de/
Fon: ++49+7073/50061-6, Fax: -5, Gaertnerstrasse 6, D-72119 Entringen
 
P

Phil Covington

Armin Steinhoff <[email protected]> wrote:

>IMHO the basic concept of the Win32 API doesn't allow reliable applications.
>For instance ... please have a look to the calls for interprocess communication.

I am familiar with the Win32 API. Are you sure that you are? Please give a specific example of why the "calls for interprocess communication" won't allow reliable applications.

>>How do you justify that statement? Not fully object oriented? Ha!

>E.g. there isn't supported INHERITANCE for the COM interface.
>Inheritance is THE core of any true object orientation!

COM doesn't support MULTIPLE INHERITANCE...

I was not trying to argue that COM is fully object oriented. I was taking issue with your statement that because COM is not fully object oriented, this is a "good" technical reason not to use it. My response was obviously not clear...

The Linux kernel is not object oriented, is that a "good" technical reason to avoid writing applications for Linux?

There are no perfect solutions to everything whether we are discussing a component object model, object oriented vs. procedural programming, or operating systems. COM works, CORBA works, they both solve a problem with
varying degree of success and "openness". Both are "useful" solutions To attack COM because the idea originated at MS is IMHO "wrong".

Regards,

Phil Covington
 
P

Phil Covington

Edelhard Becker <[email protected]> wrote:

> Windows (including 2000) is _by_design_ a Desktop-OS for Personal
> Computers, which means: switch the PC on, do some calculations in
> Excel, write a letter, print it and switch the PC off again. Unix is a
> multi-user, multi-tasking OS, which means: run the OS endlessly and
> serve as many users and as many processes as the system allows
> (depending on CPU power and memory size). Therefore it has a
> completely different design.

Windows NT is not as unreliable as many *nix advocate make it out to be. I have had very positive experiences with NT/2000. I have had positive experiences with Unix and Linux also. I know of others that have not had positive experiences with Linux. Armin made a very generalized statement concerning Windows reliability. I could easily make other generalized statements about Unix or Linux, but I am sure a OS flame war would ensue that the moderator would quickly stamp out... :)

> > > [..]
> > > There are other good technical reasons in field not to use COM ...
> > > e.g. it is not fully object oriented.
> >
> > How do you justify that statement? Not fully object oriented? Ha!
>
> - DCOM IDL does not support exceptions [3,4].
> - All DCOM methods must return HRESULT (a 32 bit integer), nothing
> different, especially no arbitrary object [3].
> - The programmer must manually take care of the server's reference
> counting (AddRef() and Release()) [3,4]
> - COM does not support multiple inheritence [4]
> - For object persistence, the client has to know the server's storage
> media, the path to the location etc. [4] (or it uses MTS, a
> completely proprietary Microsoft Service)
> - The only possibility for code re-use (one of the fundamental
> advantages of OO programming) in the COM IDL is aggregation, but
> every member function of the included class which is needed by the
> application again has to be explicitely declareted [3]
>
> Would you call that object oriented?

No I wouldn't...

Armin stated that there are "good technical reasons in field not to use COM ... e.g. it is not fully object oriented."

I was not arguing that COM is fully object oriented. I was taking issue with his argument that because COM is not fully object oriented, the fact that it isn't is a "good" technical reason not to use COM.

I don't care that it is not fully object oriented by your definition. There is a lot of "good" software written that uses COM. I prefer the word
"useful" over "good" to describe software myself.

> Because COM is such a poor technique, it does not prevent many
> companies to invest much time, money and other efforts into it to get
> some usable (maybe even good) software. Microsoft is the leading force
> in the market ("leading" by means of marketing and market share, not
> technology, visionary developments or software quality --- IMHO we all
> agree on that). By including COM, DCOM, ActiveX, OLE, VBA etc. etc.
> into their development environment, they make it very easy for
> programmers to start off without the need to evaluate other
> techniques, tools etc. But the IT world is not, and will never be, a
> streamlined, Windows-only world, so every programmer should prefer
> truly open, interoperable standards.

It is your opinion that COM is a "poor" technique. COM is a "useful" technique as evidenced by all the software out there that is built and communicate through COM based components. I do not buy the argument that
because MS and Windows dominate the market, companies have to choose a "poor technique" such as COM to try to make "good" software. Look at MS Windows CE... Palm OS is kicking MS's rear so far. People tend to pick the most useful solution to their needs...

Operating systems, along with the software that runs on them, are only tools. I don't prefer one OS over another in all cases as no one OS is
adequate for all possible uses. Allegiance to any OS is just silly, IMHO.

Regards,

Phil Covington
 
A

Armin Steinhoff

At 08:09 21.04.00 -0400, Phil Covington <[email protected]> wrote:
> Armin Steinhoff <[email protected]> wrote:
>
>>IMHO the basic concept of the Win32 API doesn't allow reliable
>>applications. For instance ... please have a look to the calls for interprocess
>>communication.
>
>I am familiar with the Win32 API. Are you sure that you are?

Sure ... I know it from a conceptual point of view.

>Please give a specific example of why the "calls for interprocess communication" won't
>allow reliable applications.

Just a simple example by the SendMessage() call ... it's commented in the Win32 API docs in the following way:

"If the given window was created by the calling thread, the window procedure is called immediately as a subroutine. If the given window was created by a different thread, Windows switches to that thread and calls the appropriate window procedure".

That means in the second case that the SendMessage call of the sending thread will return successfully only and only if the "window procedure" of the receiving thread runs properly.

That's curious ... because the interprocess communication depends on the quality of the code of the threads which are using it =:-/ . Strange
concept ....

>>>How do you justify that statement? Not fully object oriented? Ha!
>
>>E.g. there isn't supported INHERITANCE for the COM interface.
>>Inheritance is THE core of any true object orientation!
>
>COM doesn't support MULTIPLE INHERITANCE...

INHERITANCE is by definition a MULTIPLE INHERITANCE ... any other definition makes no sense, IMHO.

>I was not trying to argue that COM is fully object oriented. I was taking
>issue with your statement that because COM is not fully object oriented,
>this is a "good" technical reason not to use it.
> My response was obviously not clear...
>
>The Linux kernel is not object oriented, is that a "good" technical reason
>to avoid writing applications for Linux?

Well ... I can write OO apps based on the LINUX kernel, but that doesn't mean that the LINUX kernel is object oriented.

>There is no perfect solutions to everything whether we are discussing a
>component object model, object oriented vs. procedural programming, or
>operating systems. COM works, CORBA works, they both solve a problem with
>varying degree of success and "openness". Both are "useful" solutions To >attack COM because the idea originated at MS is IMHO "wrong".

Sorry ... that's not my point. I would always choose an open communication platform, because I don't want to be screwed up by a proprietary one.

Regards

Armin Steinhoff
 
Top