WS-Eventing and WS-Discovery implementations, as well as UDP Transport! It would also be nice to use HTTP transport if not running IIS... I'm writing these myself, but it would be nice if it were in the core.

- Jon

Jon, send me email so I can discuss this with you further if you have cycles rdias@m...

I would like to see:
WSRM support
An in-memory transport
An MSMQ transport (I know a couple of people are working on this)
and
generally more messaging and less distributed object crap.

Easy-peasy: WS-RM and WS-C and WS-AT/BA. Oh and a cheeky little one might be WS-CAF too :-) Jim

how about fixing some of the base problems, instead of piling more stuff on. do something about the specified flags when you have minOccurs='0' elements, it hideous to have to write code like
SomeStruct s = new SomeStruct();
s.IsClosed = true;
s.IsClosedSpecified = true;
err, hello, i heard C# supports property get/sets :)

Jim, you make me laugh. Do you have a scenario on why you want the transactions impl?

Jon, for in memory, can you describe the deployment scenario that makes you need this?

Simon, I believe what you are asking for will be in "Whidbey", Framework 2.0 by default. From Yasser - "This is a serialization ask. We’re handling the nillable=’true’" Does this solve your problem?

I believe its a minOccurs='0' issue, not a nillable='true' issue. out of interest, how do you decide what becomes a .NET vX.Y feature and what becomes a WSE-X feature ?

SOAP, WSDL, UDDI are not in WSE. Everything above that could/would be in WSE.

Re: In-memory transport

For those of us who like the messaging paradigm of WS (and WSE), we need a nice, efficient in-memory messaging infrastructure for cross-process/cross-appdomain communication. We'll get this with Indigo, but until then we need something. Currently, we can use System.Messaging, but that always goes cross-process to the MSMQ process. And, please, don't suggest Remoting, that is exactly what I want to get away from.

I Rebecca, here is my wish list about WSE3: WS-RM; native MSMQ Transport; "WSEWSDL3.exe /server"
to have a SoapService implementation from a WSDL contract; somehow .NET Compact Framework support; SoapClient code generated by WSEWSDL3 able to handle asynchronous calls like WSDL.EXE does, this one just for simplicity and to help lazy customers :-) to write good code. Thanks for your daily work on WSE!

Soap With Attachments (SwA) support. It's very important, altought a competitor of DIME.

I got the PDC release of Whidbey up and running, but it does exactly the same as .NET, my proxy class has fields not properties :(

public System.DateTime CreatedDate;

[System.Xml.Serialization.XmlIgnoreAttribute()]
public bool CreatedDateSpecified;

please please please please please please please please please please please please please please please please please please fix this, this is the #1 issue .NET users run into with our service.

Jeff, Why SwA? Are you aware of the composability problems with both SwA and SOAP with Attachments. The encoding format is really quite irrelevant. DIME has better perf than MIME, but in the end, it is not the issue. The issue has to do with composability. MTOM is the way of the future. Current POR is to look at this for WSE 3.0.

Support for defining encoding explicitly (config or the *options class) at the transport level.

Adding to the wish list for WSE 3.0: SAML token profile support for authentication. Also hooks into AD to represent a Windows principal (or .Net Principal) as a SAML auth token.

3-way scenario with WS-SecureConversation out of the box (tokenIssuer and targetServer are different endpoints or even v-dir), instead of implementing own custom token Issuers (aka WS-Trust) would be a gr8 feature in WSE3.0 Thanks.

Softwaremaker. Can you give me more details on your scenario? I believe we already support this.

David Marteney, we may be able to turn this feature on is SP2, can you email keithba and I (rdias) directly with more details.

Yves, can you explain why you want this? Feel free to email keithba and myself directly.

Hi Rebecca and Thanks for responding.

My assumption of a 3 way scenario is for the tokenIssuer to be decoupled from the targetService in a WS-SecureConversation using a Security Context Token.

1) Client A sends a RST requesting for a SCT to Issuer B signed with
ClientAUsernameToken and encrypted with IssuerBX509CertPubKey
2) IssuerB verifies and decrypts the message with IssuerBX509CertPrvKey
3) IssuerB sends a RSTR back to ClientA a SCT
4) ClientA received SCT and sends it to ServiceC
5) ServiceC verifies that the SCT must equal to IssuerB Token

This is somewhat similar to the CustomX509Token that comes with WSE2 RTM. However, I intend to use the SecureContextToken and not build my own Custom Token for that purpose.

I hope I am making some sense here and this is at all possible.

Rebecca, on another note, I would also agree with Simon Fell (above) on not piling too much *new* things on. The entire market is still rather behind and I havent seen much implementations in the field of WS-SecureConversations, WS-Trusts and the likes.

Interoperability is also an issue if you keep piling on the stuff. Not just with other pre.NET stuff but with other vendor's toolkits as well. AFAIK, WSE is way ahead of its competitors. IBM's ETK is not even supported.

I am just concerned that we are forgetting one of the big promises of XML Services, which is Interoperability, and we are all assuming that all the messages flying around are all created by WSE, which they are not. (Even though I wish they are). How many WSE-unaware messages would be able to communicate with a WSE-aware service ?

So a rework of what is in WSE2.0, like making the programming model more streamlined and easier and coming up with better documentation and better examples in the documentation would be a good thing. I, personally, find the programming model of WS-SC and WS-T quite a chore to look at. I dunno. Maybe its me, maybe its the documentation. The WS-Security tokens is a good example of good evolution where its so much simpler to look at and streamlined to code. Of course, it took quite a while to get here BUT its a step in the right direction.

WSE-* == Too much of a good thing

PingBack from http://paidsurveyshub.info/story.php?title=reckless-ws-eventing-implementation