Well Microsoft, IBM and somebody else have released the WS Security "spec" (whitepaper) to address some security issues with SOAP, namely message-level digital signature and encryption. It's technically clean, if a little light on detail.
Things to note (strategic):
None of SOAP, WSDL, UDDI, and now WS Security are "Royalty Free".
SOAP isn't a de jure standard -- it's a W3C "note".
UDDI was supposed to move into an open standards body in 2001 but still hasn't.
By publishing WS Security on their websites and through no open standards body we see Microsoft, IBM and that other company abandoning even attempts to appear open.
On the technical side -- if you want to see a little deeper into the security issues left unsolved by SOAP, I recommend you look at the OASIS technical committee specification, ebXML Message Service Specification version 2.0 rev C.
I've got a better question: why aren't you using the RDBMS?
Many of us who crow about the wonders of OO programming environments, don't have a firm grasp of the alternatives, nor do we fully appreciate the problems that those OO environments solve versus the good things they traded away. For building significant, long-lived, scalable, evolveable, administerable, restartable information systems the RDBMS has not been beat.
If we start from the opposite side, i.e. we start with the RDBMS and ask: what is it that is distasteful about programming in this environment, we might actually get somewhere. If I take Oracle as an example and compare it to e.g. Java the only shortcoming I see with Oracle's PL/SQL is that it doesn't (to my knowledge) support polymorphism. It does support encapsulation and abstraction (functions, procedures, packages with data hiding), and the biggie: declarative, optimizable association specification. It certainly supports "structured programming". Are you willing to trade away all that RDBMS goodness just to get polymorphism. Seems like a poor tradeoff.
I'll go even further. It is not at all obvious that the OO "model" is superior to the relational one. These observations from this paper by McCarthy apply just as well now to OO models, as they did to non-relational (accounting) models back in 1982 (pp 554-555):
(2) Its classification schemes are not always appropriate. The chart of accounts for a particular enterprise represents all of the categories into which information concerning economic affairs may be placed. This will often lead to data being left out or classified in a manner that hides its nature from non-accountants.
(3) Its aggregation level for stored information is too high. Accounting data is used by a wide variety of decision makers, each needing differing amounts of quantity, aggregation, and focus depending upon their personalities, decision styles, and conceptual structures. Therefore information concerning economic events and objects should be kept in as elementary a form as possible to be aggregated by the eventual user.
What McCarthy is arguing for is dis-encapsulation! Anti-OO. I think there's an important lesson there.
So the question is: can we have that flexibility along with maintainability?
Also, be careful to avoid reasoning from an outdated view of the data type expressiveness offered by the modern RDBMS. All the major vendors are now offering so-called OO/Relational features such as object identifiers, large objects, arrays, structures, sub-tables.
How does the commercial US electric power network store energy? There has to be some buffer between supply and demand. Capacitance in lines isn't sufficient is it?
Actually The Open Group (nee XOpen) has a product called COMsource. It's essentially a source code license for a Solaris port of Microsoft's DCOM implementation. From the COMsource page, here's what it is:
COM (including DCOM, Service Control Manager, Structured Storage, Monikers and Automation), MS-RPC, Registry, and the Windows NT® Distributed Security provider
I was investigating using it to do a pure Java implementation of DCOM, but the licensing conditions were such that it didn't look like I'd be able to deliver my stuff on Windows -- gee... all I wanted to do was "embrace and extend"
Visual J++ was arguably the easiest environment in which to do COM programming (including MTS and later COM(+) (managed) components). It wasn't perfect though.
Seems to me that the biggest opportunity for C# is to have a language that _really_ fits (embodies) the COM object model. From my reading of the C# docs though it is unclear to what extent C# really achieves that. For example there is no mention of how some sophisticated/obscure/INTERESTING COM features such as "tearoff" interfaces will map to C#.
Sigh.
1GHz clock speed and 64 MB of RAM... what would Gene Amdahl say? (for balanced system performance you need 1MB main memory per 1MHz memory bandwidth per 1MHz CPU speed) Granted we don't stick too close to that on most PC's but this is just way out of whack!
Opening API's would help, but there is a deeper problem. What is the process by which new Windows API's get created? I'll bet the "Apps" division has some (lots of) influence. It's one thing to see and understand what's there. It's quite another to drive the requirements.
It would be interesting to do a formal study on historical versions of Windows and MS Office apps and look at the date on which a Windows API is first available (in the retail OS) versus the date when that API is first exploited in a MS Office app. It would be interesting to compare those times with similar times for some third-party Windows apps.
This might give an indication of the relative advantage which the synergy of the "one big company" gives Microsoft.
Did anyone else notice that number 1 ("topsecret") has been "up" longer (1994 days or about 5.463 years) than the FreeBSD (2.0) release which it runs has been available (according to http://www.freebsd.org/releases/ it's only been available since November, '94 or about 5.167 years)?
Slashdot Mirror
Things to note (strategic):
None of SOAP, WSDL, UDDI, and now WS Security are "Royalty Free".
SOAP isn't a de jure standard -- it's a W3C "note".
UDDI was supposed to move into an open standards body in 2001 but still hasn't.
By publishing WS Security on their websites and through no open standards body we see Microsoft, IBM and that other company abandoning even attempts to appear open.
On the technical side -- if you want to see a little deeper into the security issues left unsolved by SOAP, I recommend you look at the OASIS technical committee specification, ebXML Message Service Specification version 2.0 rev C.
I've got a better question: why aren't you using the RDBMS?
Many of us who crow about the wonders of OO programming environments, don't have a firm grasp of the alternatives, nor do we fully appreciate the problems that those OO environments solve versus the good things they traded away. For building significant, long-lived, scalable, evolveable, administerable, restartable information systems the RDBMS has not been beat.
If we start from the opposite side, i.e. we start with the RDBMS and ask: what is it that is distasteful about programming in this environment, we might actually get somewhere. If I take Oracle as an example and compare it to e.g. Java the only shortcoming I see with Oracle's PL/SQL is that it doesn't (to my knowledge) support polymorphism. It does support encapsulation and abstraction (functions, procedures, packages with data hiding), and the biggie: declarative, optimizable association specification. It certainly supports "structured programming". Are you willing to trade away all that RDBMS goodness just to get polymorphism. Seems like a poor tradeoff.
I'll go even further. It is not at all obvious that the OO "model" is superior to the relational one. These observations from this paper by McCarthy apply just as well now to OO models, as they did to non-relational (accounting) models back in 1982 (pp 554-555):
(2) Its classification schemes are not always appropriate. The chart of accounts for a particular enterprise represents all of the categories into which information concerning economic affairs may be placed. This will often lead to data being left out or classified in a manner that hides its nature from non-accountants.
(3) Its aggregation level for stored information is too high. Accounting data is used by a wide variety of decision makers, each needing differing amounts of quantity, aggregation, and focus depending upon their personalities, decision styles, and conceptual structures. Therefore information concerning economic events and objects should be kept in as elementary a form as possible to be aggregated by the eventual user.
What McCarthy is arguing for is dis-encapsulation! Anti-OO. I think there's an important lesson there.
So the question is: can we have that flexibility along with maintainability?
Also, be careful to avoid reasoning from an outdated view of the data type expressiveness offered by the modern RDBMS. All the major vendors are now offering so-called OO/Relational features such as object identifiers, large objects, arrays, structures, sub-tables.
How does the commercial US electric power network store energy? There has to be some buffer between supply and demand. Capacitance in lines isn't sufficient is it?
COM (including DCOM, Service Control Manager, Structured Storage, Monikers and Automation), MS-RPC, Registry, and the Windows NT® Distributed Security provider
I was investigating using it to do a pure Java implementation of DCOM, but the licensing conditions were such that it didn't look like I'd be able to deliver my stuff on Windows -- gee... all I wanted to do was "embrace and extend"And how much does 256 MB of RAM _cost_ today? Someone needs to wake Rumpelstiltskin.
Visual J++ was arguably the easiest environment in which to do COM programming (including MTS and later COM(+) (managed) components). It wasn't perfect though. Seems to me that the biggest opportunity for C# is to have a language that _really_ fits (embodies) the COM object model. From my reading of the C# docs though it is unclear to what extent C# really achieves that. For example there is no mention of how some sophisticated/obscure/INTERESTING COM features such as "tearoff" interfaces will map to C#. Sigh.
1GHz clock speed and 64 MB of RAM... what would Gene Amdahl say? (for balanced system performance you need 1MB main memory per 1MHz memory bandwidth per 1MHz CPU speed) Granted we don't stick too close to that on most PC's but this is just way out of whack!
Opening API's would help, but there is a deeper problem. What is the process by which new Windows API's get created? I'll bet the "Apps" division has some (lots of) influence. It's one thing to see and understand what's there. It's quite another to drive the requirements.
It would be interesting to do a formal study on historical versions of Windows and MS Office apps and look at the date on which a Windows API is first available (in the retail OS) versus the date when that API is first exploited in a MS Office app. It would be interesting to compare those times with similar times for some third-party Windows apps.
This might give an indication of the relative advantage which the synergy of the "one big company" gives Microsoft.
Did anyone else notice that number 1 ("topsecret") has been "up" longer (1994 days or about 5.463 years) than the FreeBSD (2.0) release which it runs has been available (according to http://www.freebsd.org/releases/ it's only been available since November, '94 or about 5.167 years)?