[cap-talk] Scope/span of capability systems

[Ben Kloosterman]

>
>Ben Kloosterman wrote:
> > The main issue for DLL was developers NOT following specifications.
>
>That specifications have a single meaning, that they are sane and
>usable, that they are sufficiently up to date to have some faint
>connection to reality, and so on and so forth, becomes less and likely
>as the tasks to be done and the number of people involved become larger
>and larger.

True but it's worth stating the main issue with DLL hell was not standards having multiple meanings  , users were meant to write their own DLLS ; They decided it was easier to hack existing libs. So the real cause of dll was an ignoring of standards and an almost malicious changing of runtime libs and a callous disregard for other apps that may be on the same system. A secondary and still serious issue was the lack of version support but adding the version to the name solved that in most cases.

>
> >> What we need is something like MIDL, but defining
> >> messages,
>
> > Isn't that exactly what the  SOA ( Axis and WCF) stacks
> > do using wsdl?
>
>In theory, except that one WCF implementation fails to work with another
>and one SOA implementation fails to work with another - even though WCF
>is whatever Microsoft decides that it is, it seems that Microsoft
>suffers from schizophrenia.  Any solution that is based on "Let everyone
>be compatible by doing things the same way" tends to wind up like that.

I have never seen a WCF app not work with another WCF app .  Some people use WCF like a distributed Object systems and hand code object reference extentions into a context these systems will obviously fail to be interoperable.  If you use basic types like most people you won't have an issue ( with the exception of Datetime use DateTime? Instead of Datetime since Java allows null times) . 

> Any solution that is based on "Let everyone
>be compatible by doing things the same way" tends to wind up like that.

WCF is firmly based on the WS standards. However people want to do things their way eg distributes object people will try to force a context , interfaces and inheritance into the WCF Messages since these messages are XML  , since XML can't support it the solution is  proprietary. However most WCF and Axis systems are standard.

While not the only method XML solves the critical issue of backward support which nearly all binary methods had while you can define an interface you can serialize it.


>Also SOA and WCF is built on top of http, and has large overheads, while
>MIDL is high efficiency in the case of a single threaded process (though
>the various hacks designed to extend MIDL to multiprocessing are apt to
>produce intolerable inefficiencies.)  

This is a common fallacy . The overhead is negligible compared to the latency of cross machine or even cross process communication , 1ms is a long time for modern CPUs to translate messages.   In fact It has been shown that WCF is faster than binary .NET remoting , binary queues and similar products in modern systems due to improved streaming , buffering , multi threaded performance  etc.  Single core figures of 25K messages per second are possible ( 25 message per ms) . In real live systems the difference will be even bigger since SOA style systems tend to make less calls and batch things up.  You also have the option of using soap over tcp and udp ( instead of http) but this is only supported by WCF and not Axis which is always Soap over http however you can use the fast transport between wcf systems and configure an http endpoint for external system access. 

>One could not use WS-* for the
>capabilities one wants to manage access by programs to a file system.

You mean WS-Addressing or WS-Security , why can't these be used , security has like 10 different ways of doing security ?  

Not sure what the rest means....Why access to a file system , what about ROM based embedded OS that have no file systems ? The kernel can check the validity of the capabilities in the message which may require access to a file system in some capability systems. 

Anyway im suggesting it's better to use a standard that works and is common ,the pit of proposed standards that are never used is huge even if it is not perfect.

Regards, 

Ben