Multiple Service (class) Hosts - How to configure?

Multiple Service (class) Hosts - How to configure?

• huseyin_

  Greetings...to expand on a couple of points that Buddhike made:
  
  Indigo uses CLR types to represent services, and CLR interfaces to represent the behavioral contract those services expose to the outside world. Just as a CLR type can implement multiple interfaces, an Indigo service can implement multiple contracts. Whether you choose to implement each contract separately is going to depend on the semantics of your service -- the choice between 20 implementation classes (and 20 service hosts) or 1 class that implements 20 contract interfaces is up to you. However, I imagine that the sweet spot will lie somewhere in the middle. The deciding factors here will be behavioral semantics (as already mentioned, service behaviors are attached to the implementation type), metadata granularity (metadata is scoped to the serivice host) and to a lesser degree the amount of code you're willing to contain within one class.
  
  As to your second question about session identifiers, the current session identifier is available from OperationContext.Current.SessionIdentifier. One thing to note is that Indigo sessions are different from ASP.NET sessions in that they are declared explicitly on the contract and established explicitly through either the connection (if you're using a connection-oriented transport like TCP) or a message-layer protocol (such as WS-RM).
  
  One feature of Indigo that might be particularly helpful for your scenario is per-session instancing. You set this up on your service (by decorating the implementation type with [ServiceBehavior( InstanceContextMode = InstanceContextMode.PerSession )]. In this mode, we'll spin up a new instance of your service implementation each time a new session starts and guarantee that all subsequent messages that come in on that session are dispatched to the same implementation instance. You could simply initialize the COM object in the constructor of your service implementation and rely on per-session instancing to do the hard work for you.
  
  Finally, on the subject of ExecutionContext -- we don't have anything like Remoting's ILogicalThreadAffinitive marker that causes us to implicitly flow contextual information across the wire. In the WCF world, contextual information is carried in the message headers, and usually has some associated metadata that describes what information items clients can expect to be present in those headers. This is one of the ways we achieve interoperability with non-.NET clients -- if they can craft up the expected SOAP header and stick it in the message before they send it out, you'll be able to read it.
  
  For common elements of context (specifically related to the areas of security, reliability, and transactions), we've worked hard with our industry partners to come up with a common way of representing things like client credentials in a SOAP message. These are the WS-* protocols you might have heard of. WS-Security defines interoperable ways of carrying client credentials on the wire, so if you're non-.NET client speaks the WS-Security wire protocol they can interop with Indigo.
  
  Indigo gives you an easy way to deal with app-specific context items that may not be covered by the WS-* stack. You can use our typed messaging model, which gives you ean easy way to control the shape of the message we send on the wire. We also have two interfaces -- IProxyMessageInspector and IStubMessageInspector -- that allow your application code to sniff messages as they come off the wire but before they hit your app code. One of the things you can do here is add and remove your app-specific header. By writing a small amount of glue code in a Behavior, you can easily attach this new code to services without having to make each and every method implementation aware of the new functionality. Finally, if you're using these context items to do protocol-ish things specific to the demands of your application, you can plug in at the binding level and write your own protocol channel. What approach you choose depends on what you want your local programming model to look like (single-paratemer methods vs multi-parameter methods), whether you need to provide custom metadata to non-.NET clients, and how much work you want to do to plug into the Indigo architecture.
  
  Happy hacking!
  -steve
  
  

• Humphery

  BTW: I must say that you will not have to worry about the number of servicehost instances when the WAS (Windows Activation Services) comes out. It will let you host your services just like in IIS but it will also support tcp, ipc and msmq. However as of today this feature will be available only in Windows Vista.
  
  
  

• Pïeter

  Buddhike & Steve,
  
  Thanks for the information. It really helped me a lot. Now I'm more inclined towards creating a monster (wrapper) class which is going to implement all of my business interfaces and then delegates to the real business classes. This way I can write MessageHeader to CallContext mapping code in the default constructor of this service class and also on the client side I created a wrapper function for service object creation and there I'm converting the (client) CallContext to a MessageHeader. I think this may look like a poor man's implementation of IProxyMessageInspector / IStubMessageInspector!
  
  As for the left-over objects in CallContext, I'm implementing the clean-up code in IDisposable.Dispose() of the service class. Indigo is caring enough to call the Dispose method on my service.

  Are there any performance issues realted to creating the instance of this service class with >20 interface implements

  Once again, I really appreciate your insight on this matter.
  
  Thanks.

  
  

• Kosher Coder

  My two cents
  
  1. This is one of the most interesting questions I saw in the forum ;-).
  In theory, yes, you need to have 20 service hosts in order to host these services. However you could also think about normalizing the implementation so that one service class can implement several interfaces. In this case you have to make sure that these services have the same behavior (i.e. they should have the same instancing, transaction semantics).

  2. You can set your InstanceContextMode to PerSession to preserve the state between several message exchanges. If you want to access the session id in your method implementation, you could use the OperationContext.Current.SessionIdentifier property. 
  

  BTW: I’m also really looking forward to seeing the ideas from the team.

  Cheers

  
  
  
  

• ashish1482

  Hi Steve, Buddhike, All,
  
     Would you expand on how best to implement app-specific dispatching within Indigo architecture  Would you recommend a switch statement based on a header field As shown in the WCF Basic example, Default Message Contract, http://winfx.msdn.microsoft.com/library/default.asp url=/library/en-us/indigo_samples/html/5a200b78-1a46-4104-b7fb-da6dbab33893.asp. Or would designing a custom protocol channel make better use of WCF If yes, would you point to an example
  
     I'm considering the design of a distributed workflow system. Each workflow may publish or subscribe to any workflow on any machine in a network. Each instatiated workflow is required to run at all times.
  
  Scenario 1. A singleton WCF ServiceHost may be hosted within an NT Service on each physical machine. Each WCF ServiceHost would be reponsible for dispatching messages to and from hundreds of distinct workflows on local and remote machines. Dispatching to a target workflow may be accomplished through a switch statement using a header field.
  
  Scenario 2. Same as scenario 1, but Indigo architecture is used without the switch statement.
  
  Scenario 3. One SeviceHost is instantiated per workflow. Hundreds of ServiceHosts are instantiated. Additional ServiceHosts may be added over time.
  
  
  Kind Regards,
  
  Rana
  
  
  
  
  
     
  
    
  
• Multiple Service (class) Hosts - How to configure?