Keith is the Microsoft Program Manager for WSE. He works on the XML Messaging team. He's going to give us a preview of the next version of WSE.

Keith is writing a console app to allow us to heckle him during his talk.

New namespaces:

• Microsoft.Web.Services.Addressing
  
• Microsoft.Web.Serviceis.Messaging
  
• (maybe more?)
  

New classes:

• SoapService/SoapClient (kind of like .asmx, but a bit lower level)
  
• SoapService
  
  
  
  • All methods have a [SoapMethod()] attribute to define the SoapAction
    
  • Any SOAP method takes one parameter: either a SoapEnvelope (which is just a DOM) or a strongly-typed version of the message body.
  
  
• SoapReciever
  
  
  
  • 
    Looks a lot the RemotingServices.RegisterChannel()!
    
  • "Map requests coming on xxx URL to an instance of the xxxSoapService type"
    
  
  
• SoapClient (recieves SOAP messages)
  
  
  
  • take a URI to the service as a parameter to the constructor
    
  • concrete clients end up calling SoapClient.SendOneWay( soapMessageName, data )
    
  • Presumably another Send() function for doing request/response
    
  
  
  Very similar to what you get with ASMX, but allows you to go deeper/away from RPC-style
  Allows direct access to the XML content of the SOAP body. IE, you are not at the mercy of the XmlSerializer.
  
  KeithBa's definition of RPC:
  
  
  
  • Tight Coupling
    
  • High-fidelity with type systems
    
  • Synchronous
    
  • Easy to use
    
  
  
  Note that this is very different from Dave Winer's definition of RPC, which was (almost violently) pointed out several times.
  
  
  Scalability gets hard with synchronous processing. As long as the client requests themselves come synchronously. Real-world services have to juggle multiple simultaneous requests and manage finite resources. This is because all clients are keeping resources around waiting for their individual synchronous requests to complete. Solution: move towards ansyc client requests.
  
  New classes to support publish/subscribe:
  
  
  
  • SubscriberPort (keeps track of who's subscribed to your event) [Note: probably hand-jammed and not natively supported in WSE2.0]
    
  • SoapSender (broadcasts an event to all subscribed parties)
    
  • SoapReceiver (passively listens to received messages -- either events, or subscriptions to events)
    
  
  "Dialogs" are virtual connections between two notes
  Queues allow reliable and persistant dialogs that live across system resets
  
  Enter WS-ReliableMessaging!
  
  But...Reliable Messaging is not a feature of WSE2 at this point in time.