Monday, July 16, 2007 - Posts

• Local Settings and Policy

  You have talked in the past about how a service has both local settings and settings that are shared through policy. How can I transmit all settings through policy to the client? The two types of settings are clearly distinguishable. Shared settings are required to have agreement between the client and server for the two to interoperate. Examples of shared settings are the protocols and formats being used to transmit messages. Local settings are not required to have agreement between the client and server for the two to interoperate. Examples of local settings are the limits for the time and space allowed to process a message. Local settings can not only be in disagreement between the client and server, but they frequently do not make sense to share between the two. The messages sent between the client and server are rarely symmetric. The processing resources available to the client and server are rarely the same. The security concerns of the client and server are rarely in agreement. You can transmit local settings by creating your own policy assertions that both sides implement. This will involve a lot of hassle, particularly if the service wants to have local setting values that are different than those sent in the policy. Finally, the client will need to absolutely trust the service because you are asking the user to run with settings that were supplied by a third party. Why do you want to do this using policy? It seems that if you have such a level of trust with the client, then you probably already have more direct ways of pushing configuration and executables to the client machine. Next time: Enabling Performance Counters Read More... Posted Monday, July 16, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Service Architecture, Quotas, Service Model, Proxies

• Web Services Interop Plug-fest - 10-12 July 2007

  On July 10-12, Microsoft hosted the fourth successful WS-* plug-fest with a total of nine web services stacks from seven interop partners (BEA, Higgins, Iona, Oracle, Sun, VeriSign, WSO2/Apache). The scenarios tested included both the submitted web services specifications (previously supported in Microsoft’s .Net Framework 3.0 / 'Indigo' release), and the recent OASIS standards updates (new in Microsoft’s upcoming .Net Framework 3.5 / 'Orcas' release). This was the first event where we also tested some CardSpace scenarios for .NET 3.0 / 3.5 - in particular with VeriSign and the open source Higgins Project. The various interop partners were at different points in their release cycles but it was encouraging to me to see they were consistently able to show improved interoperability with Microsoft products over the course of the three days. There was a strong desire among participants to hold a follow-up event in the fall timeframe to continue to provide more coverage of the new OASIS WS-* spec versions once more interop partners have their implementations ready.... Read More... Posted Monday, July 16, 2007 5:00 AM from TheArchitect.co.uk - Jorgen Thelin's weblog | 0 Comments Filed under: Tech Interop