Dublin Q&A Post
Dublin Q&A
“Dublin” General:
1. “Will the database be managed for me by ‘Dublin’ and what will the IT Pro have to do to keep the ‘Dublin’ databases running?”
In production we expect the database be managed as any other database server in the enterprise. “Dublin” setup will add the necessary schemas and update the “Dublin” configuration to make this database the default database. You can change the default at any time using the “Dublin” tools. You can also use IIS Manager to configure specific WF and WCF services to use a different database(s). We will provide guidelines and scripts to simplify the backup and restore operations for the “Dublin” specific data to help deal with data migration and disaster recovery.
2. “Will you use Velocity for caching? In memory cache?” “Will you have a Velocity based persistence provider?”
We are evaluating the use of Velocity in “Dublin”, but currently do not plan for “Dublin” to leverage Velocity.
3. “What level of versioning support do you have?” “How will model versioning work?” “If I modify the workflow, can I also modify the return point (bookmark) in the persisted instances?” “What happens to persisted instances if I modify/redeploy the service?”
The Routing Service is a content based router capable of examining messages and then routing them to the appropriate destinations. Using this router, you can build a solution that supports different versions of your service running side by side in parallel deployment. Many different properties (such as headers, values in the message body, or destination address) could be used to distinguish between V1 and V2 messages. The Routing Service gives you visibility into these, and allows you to intelligently send messages to their corresponding service version.
4. “Is there anything in the roadmap that will bring MSE [Managed Service Engine] into ‘Dublin’ - the forwarding services looks like an embryonic implementation of this already?”
We have been collaborating with the MSE team for some time. Future versions of MSE will build upon “Dublin”, WCF 4.0 and WF 4.0.
5. “How does ‘Dublin’ add value to WCF?”
“Dublin” will make it easier to configure, monitor, and deploy a WCF service. If the service is implemented as a workflow that uses persistence, “Dublin” will add support for viewing and controlling persisted instances, scale out and other reliability features.
6. How does “Config Web” project relate to Dublin?
The Config Web project has influenced Dublin and will likely be implemented using Dublin and the .NET Framework 4.0 in a future release. It’s too early to share any additional information about the future of this and the relationship to Dublin, but we will leverage feedback from customers who have used the Config Web project as we plan future versions of both.
Tooling:
1. “Will I be able to manage/deploy to servers I don’t own (e.g. hosting on a subscription based server)?”
We are leveraging MSDeploy for deployment features in “Dublin”, and will rely on MSDeploy support for all hosting scenarios.
2. “Will you integrate the SVCEditor and TraceViewer tools into the ‘Dublin’ Tool set. Tools that enable me to see tracking and tracing information better.”
“Dublin” will provide config experience in the “Dublin” tooling; we are investigating the possible integration with SvcConfigEditor and TraceViewer tools.
3. “Will I be able to manage services across multiple IIS servers?”
“Dublin” will not provide a distributed management experience. The PowerShell cmdlets and IIS Manager extensions are designed to configure only the local server, and each server in the farm needs to be managed individually. “Dublin” will leverage the remoting capabilities in both IIS Manager and PowerShell, however, to allow the Administrator to configure multiple machines from one console.
4. “Are you going to manage persistence/monitoring databases in a distributed environment, and what is the story around clustering/partitioning this data?”
In “Dublin”, we support configuration of persistence/monitoring databases using “Dublin” management tools. Also, we support farm scenarios where identical nodes share the same persistence and tracking DBs. We rely on SQL for clustering and partitioning.
Hosting
1. “If you have 1,000 WF programs setup, do they have a common store or separate stores? Are they all querying the same database?”
In “Dublin”, persistence and monitoring databases can be configured to contain one or more isolated stores. This gives you the flexibility of creating multiple stores within one database (to simplify administration) or to create multiple databases (to improve performance). Using “Dublin” tooling you can create databases and stores and can configure where individual services write their data.2. “Can you put transaction scope around the PowerShell commands?”
We’re still evaluating which version of PowerShell “Dublin” depends upon, which will determine the answer to the question. We welcome customer feedback around relative priority for this feature.
3. "Will ‘Dublin’ support transactional services?”
WCF and WF today provide transactional services and hence “Dublin” also does.4. “Can a service be REST and non-REST at the same time?”
Yes, a service can have both a REST endpoint and a non-REST endpoint.5. “Will forwarding service be integrated/support ARR from IIS team?” “Will I be able to do load balancing with the forwarder? Just like the ARR.”
The Forwarding Service enables you to route messages to particular addresses using data dependent routing rules and so can be used to do load balancing on message content. The ARR is designed for HTTP transport whereas the Forwarder is design for any WCF transport protocol (http, msmq, tcp etc). Currently there are no plans to integrate the Forwarder with the IIS ARR.6. “Is this enterprise-ready? I have more than 100 services in a single server, will it be performing enough?”
Performance is a key measure for server products such as “Dublin”. Ensuring that “Dublin” is able to cater for large number of applications and services installed on a single server is a key goal for “Dublin”.Monitoring/Tracking
1. “Is tracking support available via API calls?”
In WF 4.0 you will be able to raise user events from within custom workflow activities by using the Track method on the Application Execution Context. Events will output based on the currently active Tracking Profile.
2. “What is your recommendation for Auditing?”
Tracking events are processed by an extensibility point, the Tracking Participant. A custom Tracking Participant can enlist in the durable instance’s transaction for guaranteed writing of audit records. An alternative is to use the standard SQL Activities to directly write to a database.
