Feedback and Questions

Nov 13, 2008 at 1:55 PM
Love the idea of this product and I'm trying to get my head around some aspects of this what were not obvious to me:

- Is it really not possible to have two operations with the same name and version? I bet I have 50 Add operations if you look at my entire service portfolio. I saw a nasty workaround someone posted for this, but that woudl be a showstopper for me. Why make things harder?

- How do you refresh an operation set from WSDL if you don't want to version it? If a service provider and consumer agree to break the interface, this should be possible.

- Is there a SIMPLE way to set up security policies? I'd love to see a way to enable common policies like client side certificates, without having to go dig for the proper XML.

- The Architecture Journal this month has an article that talks about MSE this month called "Architectural Patterns for Distributed Computing". It says explicitly on page 9 that MSE provides "Service Activity Monitoring". I didn't see any monitoring capabilities in the MMC snap in. The broker really appears to be a black box. I was hoping for something like Amberpoint that shows service usage statistics, long running operations, exceptions, etc.

- The same journal also mentions something called  Distributed Connectivity Service (DCS) but I can't find this product. What is the overlap with MSE and DCS, is DCS even available?

- Whats the future of this product vs. Oslo?

Nov 13, 2008 at 4:05 PM

We really appreciate the feedback and hope you continue to explore the possibilities of the MSE.  Here are some answers...

Operation names - yes, it is currently not possible have two operations with the same name and version.  This is actually a common question and one we continue to look at.  The current assumption with the MSE is if you are exposing services with business capabilities (ProcessOrder, AddCusomer, etc), then those capabilities would be uniquely named and largely self evident.  If two capabilities have the same name, then they would represent the same capabilitiy.  We understand this is a different mindset than standardizing on common methods accross different business services (Add, Update, Delete, Find, etc).
There are two ways to work with this (the second is prefered).
1) Have different versions of the operation represent your various Add operations.  However, versioning of each version becomes more difficult and can get out of hand quickly.
2)When you import the service, give the operation a new name in the MSE.  It doesn't matter that you have multiple service implementations with the same Add operation, you can import a Customer service's Add operation as AddCustomer and an Address service's Add operation as AddAddress.  This provides the unique name requirement and allows for a more appropriate versioning strategy.

Some additional reasoning about why we've taken this approach.  In our mind services are an arbitrary grouping of operations.  With the MSE you can easily stand up a new endpoint and expose whatever operations you want on it.  If you had multiple Add operations, you would be more limited in what you could do.  For example, suppose your company works with external vendors.  With the MSE it would be easy to consider providing each vender a unique endpoint with only the collection of operations you want them to see and have access to (perhaps AddCustomer and AddAddress). This allows your vendor to only have to talk to one endpoint, and allows you to manage one endpoint for each vendor.  Going this approach isn't for everyone or every situation but it makes inroads into the concept of consumer driven service contracts.

Overriding Operations - If you agree to break changes, then you can delete the operation and re-import the operation from the service implementation.  If you run the import service wizard on a service that has already been imported, it will only allow you to import "new" operations.  So deleting your operation and re-running the import wizard should meet your needs.

Security - This is an area our team has spent a lot of time on.  With Policies in MSE, the heavy lifting of creating the WCF behaviors and defining the XAML policy is done once.  The policy can then be applied to any endpoint you want.  That being said, we will continue to look at making it easier to implement common security policies.  This will be an iterative process.  Think about what it is you want to secure... its not really the endpoint, but rather access to the business capability.  From this perspective, the security policy is associated with the MSE's virtual capability/operation and may manifests itself differently based on the endpoint you expose that capability at.  In addition, the service implementation that corresponds to the MSE operation you are securing access to has its own security requirements that the MSE must account for and hopefully help you determine any incompatibilities between the two.  This is a very interesting topic to us and we are interested in feedback regarding how people would like to apply and manage security.

Service Activity Monitoring-  We have implemented various monitoring capabilities within the MSE on different engagements.  What was being referred to in the article is most likely a tie-in to BizTalk's Business Activity Monitoring (BAM).  BAM can be leveraged by any .Net application and we have created BAM observation models and Sql Server Reporting Services reports agains the BAM database to show activity of services (frequency, duration, caller identity, success/fail, etc.)  Although we don't publish this in a pre-built form with the CodePlex release, this functionality works merely through applying appropriate policies on the endpoints, there is no tweaking needed to the version available on CodePlex.  The MSE Runtime Service publishes events that a custom WCF behavior can hook up to to be made aware of internal processing stages of the MSE (message received, operation resolved, request sent to service, reply sent to caller).  Even without this, a simple WCF Message Inspector applied via Policy could log entries to a database to give you similar information or you could create your own BAM observation model and use the BAM api's within your custom message inspector.

DCS- You'll note that the article does mention that DCS is embedded inside of Customer Care Framework 2009.  One fundamental difference between DCS and MSE is that DCS makes the assumption that you own both the client and service.  The MSE only assumes you own the service and allows you to manage it in a world where you can't always assume the client will be on the same platform or leverage the same technology.

MSE Futures-  Our team is closely aligned with the Oslo & Dublin direction.  The MSE will leverage these technologies as they are released.  These technologies don't provide the functionality of the MSE but they will make the MSE easier to implement, essentially uplifting the platform underneath the MSE.


Nov 13, 2008 at 5:20 PM
Thank you for the reply. This answers many of my questions. Sorry to keep this going, but I can't seem to get the "testable"  functionality to work. I versioned an operation, and created a static response, marked it as testable. Re-added the operaiotn to the endpoint, stopped/started the runtime service, but it still seems to be dispatching. I don't have the old version active, so I'm confused.
Nov 14, 2008 at 9:59 PM
Edited Nov 14, 2008 at 10:07 PM
You'll need to make sure the Operation Version itself is marked as no longer Active.  If it is Active, then the static Test response won't be used.  This is a different active setting than the one that determines if an endpoint will accept messages for a specific operation version.
Nov 16, 2008 at 1:14 PM
Great, got that working now thanks. Finally, I think the one thing that appears to be missing is some way to import/export MSE configurations between environments. For example, I've got this all set up in our dev environment, now how to I move this to QA, modify all of the URLS in the monikers to point to new service hosts, etc? We have dev, qa, staging, production, and hotroll environments, so I could see this adding a bunch of work to the deployments. Its got to be something that can be automated.

Another approach would be to have a hook that allows us getting the dispatch service urls at runtime by hitting out directory service. This is how we manage it today with c# client code, but its not UDDI, its just a custom web service that manages an xml repository.
Nov 17, 2008 at 4:45 PM
The next release will have the ability to selectively export/import metadata to/from the repository through a file.  As for updating monikers to point to new locations, you could do this with a simple SQL script. Since SQL Server has native support for XML data types, it's actually pretty easy to create a script to make the change.  Using a sql script would also help with automating the address changes when moving from one repository to another.

Finally, with respect to the "hook" that would allow dynamic address resolution, you can do this by implementing a custom channel moniker.  Check out the following post for a related example:
Dec 12, 2008 at 6:15 PM
Hello All,

In fact a have to agree with bradk.

We have in our services platform a few operations with the same name in different namespaces.

From my point of view this is an namespace organization option and should be drived by the business needs. In this case it makes sense to have operations with the same name but inside different namespaces.

According to botto's post the MSE team is looking at this issue. ("Operation names - yes, it is currently not possible have two operations with the same name and version")

Can we expect that the next version of MSE will support two or more operations with the same names but inside different namespaces?

Thanks in advance.

Filipe Lima
Dec 15, 2008 at 6:23 PM
Allowing for multiple operations to have the same name is not planned.  Also, we are planning our next release to be in Februrary.
Jan 6, 2009 at 3:12 PM
Can you please post docs/guidelines and sample code on how you've implemented Service Activity Monitoring. We are planning to use MSE to host services for clients and their partners and one major requirement is service level. I would like to dig deeper on the Service Activity Monitoring and see its capabilities, etc.

Jan 6, 2009 at 3:16 PM
Can you please post docs/guidelines and sample code on how you've implemented Service Activity Monitoring. We are planning to use MSE to host services for clients and their partners and one major requirement is service level. I would like to dig deeper on the Service Activity Monitoring and see its capabilities, etc.
Jan 7, 2009 at 4:30 PM
Your best bet is probably to simply add a WCF message inspector via policy to your endpoint.  In this message inspector you can log the arrival of a message (AfterReceiveRequest) and the sending of a response(BeforeSendReply) your log could be to a queue to minimize performance degredation or to a database and would include the endpoint the message was received at and the duration of the message.  You can also minimize the impact by only writing to the queue/database once if you leverage the correlationState... for example, have AfterReceiveRequest return an object that contains the timestamp of when the message was received.  In BeforeSendReply, WCF will pass this object as the argument to the correlationState parameter thus allowing you to do all the processing/logging work in one place.

The BizTalk BAM integration is a bit more involved and isn't currently something we publish on codeplex.  However, if you are familiar with BAM observation models (, you can create one and then in your message inspector as mentioned above, you can call the BAM api's instead of writing to a queue/database.  We've used the buffered event stream to do this (