What's the planned future for the ATL Server classes Library?
With all the WS* stuff couldn’t / shouldn’t it be some improvement in the WS support, at least for the most important one's?!
Or at least provide some way for the programmer to plugin into the ATL code suport for these standards or other types of changes.
At this time, our recommendation is to use ASP.NET Web Services for developing web services. Going forward, Windows Communication Foundation in .NET 3.0 will be the preferred technology for developing SOAs. These managed frameworks provide a number of significant advantages over ATL Server, notably support for recent WS* standards, better inherent security, scalability support, and superior design-time experience. It's very likely we will deprecate ATL Server technology in the Orcas release. I appreciate your comment about potentially opening up the technology via a plugin model or something similar, and this is something we will consider for a future release.
Group Program Manager
Last edited by steixeira; June 19th, 2006 at 07:11 PM.
Steve thanks for your reply.
A few comments/explanations on why I “like” ATL Server
- Forcing a compilation to the managed world of windows services that run just fine, just to be able to publish an WS interface is somewhat overwhelming in my point of view.
- In the telecom world the term low end exists and it’s used quite often.
I really hope you would consider the “plug-in model” because would give the “!.NET World” a crack on expanding it. And since we are talking of ATL, an expansion model based on templates would just fit in quite well within the “ATL culture”. :-D
Since the current set of WS-* specs is multiple thousands of pages and the team that is writing the .Net stack to support this dwarfs the C++ team in size, we definitely cannot write a competing stack for native developers.
Since we ship full source for ATL, you can already add whatever functionality you require. It is true that the current architecture doesn't allow a third party community to easily write orthogonal enhancements and compose them, but re-architecting ATL Server to enable this is not an investment we are likely to make.
Lastly, I do want to emphasize that to expose a web service through the .Net stack you only need to compile just the piece of code that does the actual exposing as managed code (C++/CLI is the easiest way to write the code so you can trivially integrate it with your existing application) and you can keep all the rest as native code.
Acting Product Unit Manager
Visual C++ Team
I did sincerely did not expect that ATL would provide all of the WS-* enhancements, just the one regarding Security.
And although the full source of ATL comes with VC++, I already have problems moving all the small changes I make to the source code from version to version. I do not consider viable for me to that in such a grand scale. Not to mention that ATL Server depends heavily on attributes that are somewhat closed to any type of change.
Yes I find interesting the IJW stuff or the #pragma selective compilation, but don't forget that just using any of these two involves an upload of 20 Mb just to allow a a 1Mb Service to run. This is not a price I'm whiling to pay.
Uppon reading your reply I com to the conclusion that VC++ consideres ATL a dead tecnology so please just make it official. This will allow people like me to move on into another think like gSOAP or to those that can move to .NET.
>>I did sincerely did not expect that ATL would provide all of the WS-* enhancements, just the one regarding Security.<<
The problem is that ATL Server would need so much work to be competitive with the managed frameworks, the VC++ teams has to ask itself: is it worth the expediture of resources to address just one of many issues? Or would it be wiser to spend those resources in another area of the product where we believe we can have a bigger impact on the success of our customers? We're choosing the latter route here, of course. We understand and regret that decisions like this can be painful for the customers invested in the technology, but I believe it's better to deliver the bad news honestly than for customers to not know where we stand.
>>Uppon reading your reply I com to the conclusion that VC++ consideres ATL a dead tecnology so please just make it official.<<
I did say we were likely to deprecate ATL Server in Orcas. That's pretty official if you ask me.
Group Program Manager
Last edited by steixeira; June 20th, 2006 at 01:04 PM.
The problem is that ATL Server would need so much work to be competitive with the managed frameworks, the VC++ teams has to ask itself: is it worth the expedature of resources to address just one of many issues?
Just being native is a value that distinguishes it from managed frameworks. But I agree that spending resources on a product that few customers use is not what one would call a good business decision.
Well, time to look at Axis C++, I guess.
Last edited by Nemanja Trifunovic; June 20th, 2006 at 12:50 PM.
I totally understand the reason of why not move on with ATL. Besides I my opinion I think unmanaged frameworks does not go along with the grand picture of the managed world. Although ending with ATL will somewhat "remove" some of the VC++ capabilities of building unmanaged apps, because nobody uses deprecated technology.
I have to disagree with only in the part that you are saying that you stating that ATL will be deprecated makes it official. For me and others that read this post, yes I had to agree with you. But until now I've been looking at the product roadmap, and I have not read any statement that at least hints the future of ATL.
Thanks again for your reply
Last edited by Sygnosys; June 20th, 2006 at 06:24 PM.