Intel, can you provide a roadmap for AMT? Something that says AMT1.0 was implemented for Chipsets ABC, which were released (or available) from Date-X to Date-Y. AMT 2.0...
Maybe it is now a good time to also zoom in a bit on the real problem we have here.
(If the information is not there already available) we would like to know which DTK/SDK will be applicable to which Intel platforms (or AMT version rather). One particular concern for us as an implementor of AMT to date is the mention in an earlier newsletter ("Use WS-MAN Interface for Intel AMT Code" of 28Jan2008) that AMT 2.X for example will not support the WS-MAN interfaces, and that *AMT 3.0 will be the last platform to support the older proprietry SOAP calls.
* is the biggest problem of the two.
Did I understand the newsletter correctly? My company has already invested a lot into the development of the old SOAP calls.
Hi. A roadmap would be very useful. I want to answer the WSMAN vs SOAP question given that, while I work for Intel, I am also in mostly the same position that ISV's are in when building the DTK.
Intel AMT 1.0, 2.0, 2.5only supported SOAP. Intel AMT 3.0supports both WSMAN and SOAP. Intel's roadmap shows that as we move far into the future, only the WSMAN interface will be supported, also, new features will start being avaialble on on WSMAN, etc. This is a long ways off, but it the direction Intel is going.
They are doing this because they are standardizing the hardware management interface (DASH) and want to make the Microsoft Windows (WMI) and hardware management (DASH) use the same underlying protocol (WSMAN).
Now, I will tell you from my experience, WSMAN is more difficult to learn and get started with, often doing the same thing with WSMAN takes many more lines of code, etc. In the DTK, I have slowly been dual-porting each and every SOAP call to also support WSMAN so that Intel AMT Commander could run on all versions of Intel AMT using WSMAN when possible... and it's a lot of work. I don't think I have 40% of the calls ported over and I spend nights and weekends doing it. Oh yes, it's also slower... WSMAN calls are notably slower than SOAP calls.
This said, it's the price to pay for standardization. In theory, software built to support WSMAN will also work on non-Intel hardware. It's also nice if you already use WSMAN to manage other things.
People using the DTK stack will get WSMAN support for free with minimal or now changes to their own code. For people coding in C/C++ using the SDK samples, I have no good solution. I believe Intel is commited to supporting the SOAP API for some time to come, maybe Gael or others have formal releases on this topic.
Ylian (Intel AMT Blog)
I wanted to write a quick follow-up to my previous mail on the topic of WSMAN. Ever since the release of the Intel AMT DTK v0.51, WSMAN speed has improved significantly. In earlier versions of the DTK and most or all of theSDK samples, WSMAN calls where made using Microsoft's WinRM. Sadly, each WSMANcall was made using a new TCP connection, resulting is many TCP open/close and many more network round trips then necessary and so, making everything slow.
The new DTK stack has a file called WsManDirectClient.cs, this is the codefor the new WSMAN stack that is building C# and runs on top of the usual HTTP classes included in .NET and so is now very similar to the path used for SOAP calls.
I hope this new class helps many people increase the speed of their own WSMAN calls and many everything must easier for developers and users (who no longer have to worry about WinRM).
Ylian (Intel AMT Blog)