Buscar primero
WCF Y servicios de WF en .NET Framework 4.0 Y “ Dublin ”
Aaron Skonnard
Este artículo se basa en una versión preliminar de la 4.0 de .NET Framework y el Dublin. Toda la información está sujeta a cambios.
En este artículo se describen:
|
En este artículo se utilizan las siguientes tecnologías: .NET framework 4.0, “ Dublin ” |
Contenido
Mover hacia la 4.0 de .NET Framework
Biblioteca de actividades de WF base
Modelo de programación de WF actividad
WCF más nuevas características de .NET Framework 4.0
La necesidad de "Dublin"
Una guía para la "Dublin"
Creación de un servicio de flujo de trabajo WCF para "Dublin"
Implementar aplicaciones con "Dublin"
Administración de aplicaciones en ejecución
Actualizar aplicaciones en ejecución
Supervisión de aplicaciones en ejecución
¿Desde "Dublín" a "Oslo"?
¿Qué ocurre con BizTalk Server?
en la conferencia de desarrolladores profesionales (PDC, Primary Domain Controller) en octubre de 2008, Microsoft lanzó los detalles de numerosas mejoras que se incluirán en la de Microsoft .NET Framework 4.0, específicamente en las áreas de Windows Communication Foundation (WCF) y Windows Workflow Foundation (WF). Microsoft también debuted algunas extensiones a Windows Server, código de denominado "Dublin", que proporcionan un alojamiento mejorada y administración de experiencia para las aplicaciones WCF y WF.
La integración de WF y WCF en la 4.0 de .NET Framework hará más fácil desarrollar aplicaciones orientadas a servicios distribuidas. Podrá crear servicios de flujo de trabajo con estado mediante un modelo totalmente declarativo que ofrece más flexibilidad y la agilidad empresarial.
Las nuevas extensiones alojamiento y administración introducidas por "Dublin" complementan estos avances de marco de trabajo. La combinación de avances en el marco de trabajo y en las herramientas operativas que admiten el marco de trabajo significa que la capacidad del servidor de aplicación en Windows Server se efectuar un bisiesto significativo hacia delante.
En este artículo, examinará algunas de las claves nuevas WCF y WF características en el 4.0 de .NET Framework, así como las funciones de servidor de aplicaciones nuevo proporcionadas por las extensiones "Dublin".
Mover hacia la 4.0 de .NET Framework
WCF y WF son tecnologías complementarias. Si está familiarizado con ellos, una manera sencilla pensar en el par es: WCF en el exterior, WF en el interior. WCF se utiliza para exponer la interfaz de servicio externo de una aplicación, y se utiliza WF para describir el flujo interno, estados y transiciones de una aplicación.
.NET Framework 3.5 introdujo algunos atractiva integración entre los dos, específicamente en el formulario de las actividades de WF enviar y recibir. Con estas actividades, puede emplear WF para simplificar el proceso de coordinar varias interacciones de servicio para cumplir los flujos de trabajo complejos y de larga ejecución. También puede utilizar estas actividades para ampliar el alcance de los flujos de trabajo de WF, al prepararles con extremos WCF (consulte la figura 1 ). Esto básicamente permite emplear WF como la implementación para sus servicios WCF, lo que llamará los servicios de flujo de trabajo de WCF a lo largo de este artículo.
Figura 1 servicios de flujo de trabajo WCF
Aunque es posible implementar los servicios de flujo de trabajo de WCF en .NET Framework 3.5, no es fácil. Para empezar, la capa de integración entre WCF y WF deja algo que se desea. En .NET Framework 3.5, los artefactos WCF tiene que estar definido y utilizando configurado la programación de WCF y configuración de modelo, mientras que el flujo de trabajo se define mediante un modelo diferente. En última instancia, acabará con varios artefactos que necesitan para implementar, configurado y administrado por separado.
Otro motivo para la dificultad es que la biblioteca de actividades base actual se centra en actividades de flujo de control y la lógica y no proporciona gran parte en el medio de las actividades de trabajo. Por lo que debe escribir una biblioteca de actividades personalizadas antes de que se pueden implementar servicios de flujo de trabajo del mundo real con WF. Dada la complejidad de ese trabajo, algunos desarrolladores han dado copia antes de que se puede experimentar las ventajas de WF.
Junto con estos problemas, WF actual carece también compatibilidad con herramientas para el lenguaje eXtensible de marcado de aplicaciones (XAML), los flujos de sólo trabajo, que son también conoce como declarativas flujos de trabajo porque está completamente descritas en un archivo XML sin los archivos de código subyacente. El enfoque de XAML sólo crea algún flujo de trabajo atractiva posibilidades de alojamiento y la implementación. Lo eficaces sobre un flujo de trabajo declarativo es que es que sólo datos que se pueden almacena y ejecuta en un entorno en tiempo de ejecución WF que conozca acerca de las actividades utilizadas.
Se puede implementar un flujo de trabajo declarativa a un tiempo de ejecución en la nube o a una estación de trabajo en el escritorio (suponiendo que han implementado las actividades para el host de tiempo de ejecución). Flujos de trabajo declarativas también son más fáciles de versión, y pueden utilizarse en situaciones de confianza parcial (piense "nube"). El modelo de XAML sólo también es más fácil crear herramientas alrededor, ya que las herramientas sólo están trabajando con archivos XML.
En general, el modelo de XAML sólo siempre ha sido la visión del final de WF como una tecnología, es evidente en el writings anticipado por sus arquitectos. Sin embargo, la compatibilidad de herramienta actual WF completamente no apreciar que visión. Aunque es posible crear flujos de trabajo sólo XAML con .NET Framework 3.5, tendrá que solucionar las plantillas de Visual Studio actuales y renunciar a importantes características, tales como la depuración.
El objetivo principal de WCF y WF en la 4.0 de .NET Framework es simplificar la experiencia de programador alrededor declarativas flujos de trabajo y servicios de, totalmente utilizando un modelo sólo XAML. Además, Microsoft deseaba tomar una de las cosas paso más allá convirtiéndolo en posible definir los servicios de flujo de trabajo declarativa. Es decir, los servicios WCF que completamente se definen en términos de XAML, incluidos el servicio de contrato definiciones, configuraciones de extremo y la implementación del servicio real (en el formato de un flujo de trabajo en función de XAML).
Para ello, Microsoft ha realizado numerosas mejoras en la 4.0 de Framework .NET, como una biblioteca de actividad extendida de clase base, un modelo de programación más simple de actividades personalizadas, un nuevo tipo de flujo de trabajo de diagrama de flujo y numerosas mejoras específicas de WCF.
Biblioteca de actividades de WF base
El 4.0 de .NET Framework incluye una biblioteca de actividades base mejorada que contiene varias actividades nuevas (consulte Figure 2 ). Microsoft también planea comenzar a poner a disposición a través de CodePlex entre las versiones de .NET Framework principales actividades WF adicionales. También empezará ver más actividades de trabajo (que, como la actividad PowerShellCommand) aparecen en futuras versiones (o en CodePlex), con lo que reduce la necesidad de desarrollo de actividades personalizadas. Y porque Microsoft está utilizando CodePlex, tiene una buena oportunidad para realizar su opinión heard en qué actividades adicionales que desea ver.
El 4.0 de .NET Framework introduce unos actividades principales que proporcionan más opciones de flujo de control, incluidas las actividades FlowChart, ForEach, DoWhile y salto. La actividad FlowChart nueva es uno de las adiciones más interesantes porque ofrece una superficie medio interesante entre los modelos de flujo de control secuencial y StateMachine. Diagrama de flujo le permite utilizar un enfoque de paso a paso, mejorado con sencillas tomar decisiones y los conmutadores, pero también permite volver a actividades anteriores en el flujo de trabajo. En general, diagramas de flujo parecen más intuitivo para muchos usuarios. la figura 3 muestra lo que el FlowChart diseñador aspecto en el diseñador de flujo de trabajo nuevo en Visual Studio 2010 (consulte barra lateral de "el nuevo flujo de trabajo Designer" para obtener más información).
La figura 3 el nuevo diseñador de actividades FlowChart
Además, la 4.0 de .NET Framework presenta algunas nuevas actividades de tiempo de ejecución para invocar los métodos CLR (MethodInvoke), para asignar valores a las variables del flujo de trabajo (asignar) y para conservar explícitamente una instancia de flujo de trabajo que se está ejecutando (persistencia).
Por último, la 4.0 de .NET Framework incluye un nuevo conjunto de actividades en función de WCF que simplifican el proceso de exposición de los flujos de trabajo como servicios o consumir servicios desde dentro de los flujos de trabajo. .NET Framework 3.5 proporcionan dos actividades, enviar y recibir, para enviar y recibir mensajes a través de WCF. En la versión 4.0, encontrará las actividades de SendMessage y ReceiveMessage, para enviar y recibir mensajes unidireccionales (similar a enviar y recibir en la versión 3.5), así como una abstracción de alto nivel para operaciones de solicitud/respuesta a través de las actividades ClientOperation y ServiceOperation. Un flujo de trabajo que desea exponer una operación de servicio debe usar la actividad ServiceOperation. Mientras que un flujo de trabajo que desea utilizar un servicio externo debe usar la actividad ClientOperation.
Además estas actividades WCF principales, la 4.0 de .NET Framework también proporciona compatibilidad para la correlación entre distintas operaciones unidireccionales para asegurarse de que un mensaje concreto pone a volver la instancia flujo de trabajo correcto. Incluye una actividad para definir un nuevo ámbito de correlación (CorrelationScope) y para inicializar los valores de correlación (InitializeCorrelation) antes de enviar un mensaje saliente a través de WCF.
El nuevo diseñador de flujo de trabajo
Un diseñador de flujo de trabajo nuevo agregado a 2010 de Visual Studio proporciona una atractiva experiencia de usuario gráfica para muchos de las características claves de WCF y WF descritas en este artículo. Proporciona características tales como exploración de flujo de trabajo mejorado (profundizar en actividades compuestas) con herramientas de crumb pistas para volver en ámbito, actividad in situ de edición (reduce la necesidad de la ventana de propiedades), las capacidades de zoom y exploración de la información general. Además, el nuevo diseñador proporciona un modelo mejorado para personalización y el realojamiento. 2010 De Visual Studio también se ofrecen un conjunto de plantillas de proyecto nuevas o mejoradas que facilitan la Introducción rápida con diagramas de flujo de funciones y flujos de trabajo sólo XAML y proporcionarán compatibilidad total para la depuración en función de XAML al trabajar con los flujos de trabajo declarativas y servicios.
Modelo de programación de WF actividad
Incluso con estas mejoras, es posible que todavía tiene que escribir actividades personalizadas a veces. Por lo que para que sea más fácil, Microsoft rediseñado las clases base para las actividades personalizadas. La nueva clase base para actividades personalizadas se denomina WorkflowElement, y hay otra clase que deriva de denominada actividad. La clase de actividad facilita la crear nuevas actividades personalizadas de las actividades existentes sin necesidad de escribir mucho, si los hay, código.
la figura 4 , por ejemplo, se muestra cómo definir una nueva actividad personalizada llamada CopyFile por derivar de la actividad y reemplazar CreateBody. La implementación crea una instancia PowerShellCommand personalizada que es configurada para utilizar el comando copy de elemento integrada. Asimismo, puede crear actividades personalizadas como ésta con el nuevo diseñador de flujo de trabajo en 2010 de Visual Studio, mediante el diseñador gráfico actividad, si en su lugar desea evitar este tipo de código totalmente.
Figura 4 personalizada CopyFile actividad
class CopyFile : Activity
{
public InArgument<string> Source { get; set; }
public InArgument<string> Destination { get; set; }
protected override WorkflowElement CreateBody()
{
return new PowerShellCommand
{
CommandText = "copy-item",
Parameters =
{
{ "path", new InArgument<string>(Source) },
{ "destination", new InArgument<string>(Destination) } ,
{ "recurse", new InArgument<bool>(false) }
},
};
}
}
Cuando necesite definir una actividad personalizada desde cero (algo no basado en las actividades existentes), debe derivar WorkflowElement y reemplazar el método Execute. Este método requiere un poco más código, y es similar a cómo funciona actualmente al derivar de la actividad. Sin embargo, Microsoft ha simplificado aún más las cosas por escribir estas actividades personalizadas.
Uno de las cosas que hace la escritura de una actividad personalizada difícil es la administración flujo de datos dentro y fuera de la actividad. Por ejemplo, hoy en día no resulta posible definir un conjunto de argumentos con tipo que se pasan dentro y fuera de una actividad. Normalmente, los desarrolladores escritura clases personalizadas que serializan y deserializan los argumentos de un flujo de trabajo de cola (para obtener más información, consulte artículo de Michael Kennedy," Web de aplicaciones que operaciones de ejecución larga soporte técnico .") Escribir este código de fontanería no es difícil, pero es trabajo adicional que distracts desde el objetivo central de la aplicación flujo de modelado. El 4.0 de .NET Framework amplía el modelo de programación de actividad con tres nuevos datos flujo conceptos que promesa para simplificar las cosas considerablemente: argumentos, variables y expresiones.
Se utiliza argumentos para definir los flujos de datos de forma y desprotección de una actividad. Cada argumento tiene una dirección de enlace especificadas como entrada, salida o entrada y salida. En el ejemplo siguiente se muestra cómo crear una simple actividad de auditoría con un solo argumento de entrada denominado "AuditMessage":
public class Audit: WorkflowElement {
public InArgument<string> AuditMessage{ get; set; }
protected override void Execute(ActivityExecutionContext context) {
WriteToEventLog(AuditMessage.Get(context));
}
}
Las variables proporcionan un medio para declarar denominada almacenamiento de datos. Puede definir las variables en el código, así como en los flujos de trabajo en función de XAML. También se pueden definir las variables en distintos ámbitos de un flujo de trabajo (dentro de los elementos de flujo de trabajo anidados) y forman parte de la definición de programa del flujo de trabajo en tiempo de diseño, mientras que los valores se almacenan en la instancia de flujo de trabajo en tiempo de ejecución.
El ejemplo siguiente muestra cómo escribir un flujo de trabajo XAML que define una variable denominada mensaje, le asigna un valor (con la actividad de asignar nueva) y se pasa el valor de la variable en la actividad de auditoría personalizada definida anteriormente:
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<Assign x:TypeArguments="p:String" To="[message]"
Value="Audit message: something bad happened" />
<s:Audit Text="[message]" />
</Sequence>
Una expresión es una construcción que toma uno o más argumentos de entrada, realiza alguna operación o el comportamiento en los argumentos de entrada y, a continuación, devuelve un valor. Las expresiones se definen mediante derivar una clase de ValueExpression, que a su vez se deriva de WorkflowElement, por lo que las expresiones pueden ser utiliza en cualquier lugar puede utilizarse una actividad. También se pueden utilizar expresiones como un enlace con el argumento de otra actividad. En este ejemplo se define una expresión de formato simple:
public class Format : ValueExpression<string> {
public InArgument<string> FormatString { get; set; }
public InArgument<string> Arg { get; set; }
protected override void Execute(ActivityExecutionContext context) {
context.SetValue(Result,
String.Format(FormatString.Get(context), Arg.Get(context)));
}
}
Puede incorporar esta expresión en los flujos de trabajo XAML como cualquier otra actividad. Por ejemplo, el flujo de trabajo siguiente muestra cómo pasar el resultado de la expresión de formato en la actividad de auditoría para escribir el resultado en el registro de eventos (esto supone que contenido de auditoría asigna en el argumento mensaje):
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<s:Audit>
<s:Format FormatString="Audit message: {0}" Arg="[message]"/>
</s:Audit>
</Sequence>
Otro lo tenga en cuenta es que hay nada especial acerca de la actividad raíz. Todo lo que se deriva de WorkflowElement puede utilizarse en la raíz o en cualquier lugar en el flujo de trabajo. Esto le permite arbitrariamente redactar los estilos de flujo de trabajo diferente dentro de una otra (por ejemplo, una máquina de estado dentro de un diagrama de flujo dentro de una secuencia.
La mayoría de estos cambios en el modelo de programación facilitar los flujos de trabajo declarativas ciudadanos de primera clase porque ya no necesita archivos codebehind imprescindible para definir propiedades de flujo de datos, todo se puede realizar mediante declaración en XAML ahora. Sin embargo, dado que éstos son cambios bastante fundamentales, requiere algunos cambios significativos en el tiempo de ejecución WF, que, en última instancia, interrumpir la compatibilidad con las actividades de 3.x de .NET Framework (consulte la barra lateral sobre cómo migrar flujos de trabajo para obtener más información). A pesar de que, sin embargo, Microsoft cree que simplifica el modelo de programación de WF enormemente beneficiará a los desarrolladores WF a lo largo del tiempo.
Migrar flujos de trabajo a .NET 4.0
El nuevo modelo de programación actividad de .NET Framework 4.0 requiere algunos cambios significativos en el tiempo de ejecución WF principal. Como resultado, actividades personalizadas diseñadas para .NET Framework 3.0 y 3.5 no podrá ejecutar dentro de un host de flujo de trabajo.NET Framework 4.0 sin algunos atención especial.
Para facilitar la interoperabilidad, la 4.0 de .NET Framework incluye una actividad de interoperabilidad especial que facilita ajustar una actividad personalizada de 3.x .NET dentro de un host.NET 4.0. Este enfoque no funciona para todas las actividades de 3.x .NET, en concreto no funciona para las actividades de raíz. Por lo tanto, al pasar a 2010 de Visual Studio, tendrá que volver a diseñar los flujos de trabajo con el nuevo diseñador de flujo de trabajo (ya que también ha cambiado mucho), a continuación, puede ajustar actividades personalizadas de 3.x .NET mediante la nueva actividad interoperabilidad dentro de las nuevas definiciones de flujo de trabajo.
WCF más nuevas características de .NET Framework 4.0
Es fácil para ver cómo se puede implementar un servicio de WCF con un flujo de trabajo, pero realmente producir un servicio de flujo de trabajo declarativo, también tendrá una forma de definir contratos de servicio y para configurar mediante el modelo declarativo de XAML sólo las definiciones del extremo. Esto es exactamente lo que aporta WCF en la 4.0 de .NET Framework a la tabla. Supongamos que tiene esta definición de contrato del servicio WCF:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int Op1, int Op2);
[OperationContract]
int Subtract(int Op1, int Op2);
};
En la 4.0 .NET Framework, puede definir el mismo contrato mediante declaración mediante la siguiente definición de XAML:
<ServiceContract Name="ICalculator">
<OperationContract Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res1" Type="p:Int32" />
</OperationContract>
<OperationContract Name="Subtract">
<OperationArgument Name="Op3" Type="p:Int32" />
<OperationArgument Name="Op4" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res2" Type="p:Int32" />
</OperationContract>
</ServiceContract>
Ahora que tiene el contrato de servicio definir en XAML, el paso siguiente es definir cómo desea que el contrato del proyecto en la red. El 4.0 de .NET Framework presenta el concepto de una previsión de contrato para separar la definición de contrato lógico de la representación de los mensajes que se envían y reciben. Esto permite definir un contrato de servicio único que se puede previsto diferente para admitir distintos estilos de mensajería.
Por ejemplo, puede tener proyección de un contrato para la mensajería basados en SOAP y proyección otra para la mensajería rest/POX, pero ambos se basan en el mismo contrato de servicios lógicos. Éste es cómo se puede definir una proyección de contrato SOAP para el contrato de servicio sólo definida:
<Service.KnownProjections>
<SoapContractProjection Name="ICalculatorSoapProjection">
<!-- service contract definition goes here -->
</SoapContractProjection>
</Service.KnownProjections>
Con esta definición de contrato y proyección en su lugar, es posible implementar la lógica del servicio en XAML. El elemento raíz de la definición de servicio XAML es el servicio. El elemento de servicio contiene las definiciones de contrato y proyección en el elemento secundario de Service.KnownProjections. La implementación del servicio pasa en el elemento Service.Implementation (que es un flujo de trabajo declarativo). Y por último, la configuración del servicio extremo se pasa en el elemento Service.Endpoints. la figura 5 muestra la definición completa servicio declarativa en XAML.
La figura 5 declarativa del servicio de WCF
<Service xmlns="clr-namespace:System.ServiceModel;assembly=System.WorkflowServiceModel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:ss="clr-namespace:System.ServiceModel;assembly=System.ServiceModel"
xmlns:sw="clr-namespace:System.WorkflowServiceModel;assembly=System.WorkfowServiceModel"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:x2="https://schemas.microsoft.com/netfx/2008/xaml">
<Service.KnownProjections>
<SoapContractProjection x:Name="ICalculatorSoapProjection">
<ServiceContract x:Name="ICalculatorContract"
<OperationContract Name="Add" x:Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="Result"
Type="p:Int32" />
</OperationContract>
</ServiceContract>
</SoapContractProjection>
</Service.KnownProjections>
<Service.Implementation>
<sw:WorkflowServiceImplementation>
<!-- place service implementation here -->
</sw:WorkflowServiceImplementation>
</Service.Implementation>
<Service.Endpoints>
<Endpoint Uri="http://localhost:8080/calc"
ContractProjection="{x2:Reference ICalculatorSoapProjection}">
<Endpoint.Binding>
<ss:BasicHttpBinding />
</Endpoint.Binding>
</Endpoint>
</Service.Endpoints>
</Service>
Una desventaja en esta etapa anticipada es que no hay ningún diseñador visual para ayudar a crear servicios mediante declaración. Espero que como implantar la Community Technology Preview (CTPs), Microsoft ofrecer una experiencia diseñador descriptivo de programador para trabajar con la definición de XAML.
Además de a la compatibilidad de servicio declarativa y las actividades en función de WCF que se ha mencionado anteriormente, la 4.0 de .NET Framework incluye varias otras mejoras de WCF de nivel inferior. Algunas de estas características hacen posible administrar servicios de flujo de trabajo con las nuevas extensiones de "Dublin". Estas características incluyen configuración mejorada, correlación de mensajes, comunicación dúplex duradera, temporizadores duraderos y integración de seguimiento de eventos seguimiento para Windows (ETW). Otras funciones que agregan valor al alojar los servicios en un entorno administrado incluyen los extremos de control estándar y de inicio automático. Se oye más sobre estas características en los meses por adelantado.
La necesidad de "Dublin"
En el mundo real, otro aspecto difícil de trabajar con WCF y WF es saber dónde a host sus servicios y los flujos de trabajo en un entorno de servidor. La respuesta de WCF, normalmente es bastante fácil, la elección más común es IIS y Windows proceso Activation Service (WAS) en Windows Server 2008.
Hoy en día, la combinación de IIS y WAS proporciona varias características claves como proceso de activación en respuesta a los mensajes entrantes, supervisión y del estado de administración de procesos, reciclaje de procesos, CLR AppDomain integración, seguridad integrada y algunas capacidades de administración básica disponible a través de los cmdlets de administrador de IIS y Windows PowerShell. Normalmente, estas características combinadas que IIS y WAS la opción derecha para alojar servicios WCF en un entorno de servidor como la mayoría de los amigos no desean crear ese tipo de cosas a sí mismos.
Aunque IIS y WAS proporciona una base para alojar aplicaciones WCF, esté corto en algunos aspectos importantes. El mayor inconveniente se encuentra en el área de administración de servicio. IIS y WAS no realmente capacidades las específicas de WCF servicio administración como servicio de seguimiento, supervisión y diagnóstico ejecutando instancias de servicio. Por ejemplo, un administrador no lista actualmente todos los servicios WCF que están configurados en IIS, no es posible consultar el estado de todos los servicios alojados. IIS y WAS también no ofrece compatibilidad integrada para simplificar la escala, implementaciones o tareas comunes de configuración de WCF, que resulta para ser un punto débil de WCF.
Los desafíos a los host son peor para las aplicaciones de WF en entornos de servidor debido al modelo de forma inherente estado necesarias para admitir los flujos de trabajo de larga ejecución a través de conjuntos de servidores. Causa de estas complejidades, Microsoft no enviar un host de servidor WF en .NET Framework 3.0, los programadores tenían que escribir esta propios. No era hasta que .NET Framework 3.5, con la introducción de la clase WorkflowServiceHost, que era posible los flujos de trabajo de WF host como los servicios WCF de fábrica, lo que lo que permite a host sus flujos de trabajo de WF dentro de IIS y WAS así.
WorkflowServiceHost fue un buen comienzo, pero no vienen con una compatibilidad de herramientas para administrar flujos de trabajo con estado en un completo conjunto de servidores Web ni se proporcionan herramientas para supervisar y administrar las instancias de flujo de trabajo que se está ejecutando en tiempo de ejecución.
En términos de servicio y el flujo de trabajo características de administración, la mayoría de los desarrolladores esperan una experiencia similar a lo que es proporcionado por Server bizTalk, aún más sencillo. Muchas de las organizaciones desean la experiencia de administración de BizTalk, pero no tienen las capacidades de integración o la confiabilidad semántica (y detección de rendimiento correspondiente) es inherente en MessageBox de servidor de BizTalk. Un modelo de más claro de peso, diseñado específicamente para las aplicaciones WCF y WF, es más adecuado.
Una guía para la "Dublin"
Microsoft ha trabajado en un nuevo conjunto de extensiones de servidor de Windows, código de denominado "Dublin", que proporciona características de alojamiento y administración valiosos para las aplicaciones WCF y WF. " Dublin" es básicamente un conjunto de administración de servicios extensiones creada por encima de IIS y WAS se incluirá como parte de Windows Server. Al utilizar las extensiones "Dublin", le aún se alojar su servicio y flujos de trabajo de IIS y WAS, pero sus aplicaciones disfrutarán de adicionales WCF y específicos de WF capacidades de administración y las herramientas que actualmente no existen en IIS y WAS.
Las extensiones de "Dublin" distintos se incluirán en una versión futura de Server de Windows como parte de la función de servidor de aplicaciones de Windows Server. Por lo tanto, el conjunto de características a menudo se denomina el servidor de aplicaciones Windows, aunque eso no es el nombre oficial sancionado por Microsoft. Para el resto de este artículo, le consulte las nuevas extensiones de servidor de aplicaciones de Windows Server como simplemente "Dublin".
Las funciones claves proporcionadas por las extensiones "Dublin" incluyen compatibilidad de administración de servicios confiables y duraderas y flujos de trabajo de larga ejecución. " Dublin" hace posible implementar una aplicación en servidores individuales en un conjunto de servidores, y proporciona las herramientas que necesita para tareas de administración de servicio específico. Será explicar estas funciones con más detalle en las secciones siguientes, pero primero vamos a eche un vistazo a la arquitectura general, que se muestra en la figura 6 .
Figura 6 la arquitectura de “ Dublin ”
Como puede ver, "Dublin" proporciona varias bases de datos de tiempo de ejecución que distribuir una base para servicio de persistencia y supervisión. Hay una capa de componentes en tiempo de ejecución y los servicios proporcionados por .NET Framework que se crean en la parte superior de estas bases de datos. " Dublin" más extiende estas runtimes para proporcionar persistencia de alojamiento, integrado, supervisión y las capacidades de mensajería. Esta capa, en combinación con las bases de datos en tiempo de ejecución subyacente, constituye lo que se conoce como Dublin.
Las dos capas superiores en la arquitectura son qué hacer "Dublin" utilizable por los usuarios. Hay una capa de API de administración que realiza las funciones de varias secuencias de comandos a través de los cmdlets de Windows PowerShell. En parte superior de ese hay una experiencia de administrador de IIS que debe sentir familiar para los administradores IIS de hoy, ya que realmente se basa en los cmdlets de Windows PowerShell. Por lo que todo lo que puede hacer en Administrador de IIS también puede realizar en Windows PowerShell.
Microsoft ha agregado varias extensiones de interfaz de usuario para el administrador de IIS para realizar las diversas tareas de alojamiento y administración descritas en esta sección. Existen extensiones para implementar y configurar aplicaciones, administración de aplicaciones y las aplicaciones de supervisión. Estas extensiones también proporcionan un panel en tiempo de ejecución de su sistema cosas de mostrar tales como ejecutar, instancias de flujo de trabajo suspendido y almacenado.
Creación de un servicio de flujo de trabajo WCF para "Dublin"
2010 De Visual Studio facilita realmente generar servicios que las extensiones "Dublin" a través de una nueva plantilla de proyecto de destino (consulte la figura 7 ). Esta plantilla de proyecto le ofrece un web.config preconfigurado con el proveedor de persistencia "Dublin"-proporcionado y servicio de temporizador duradero.
La figura 7 de creación de una biblioteca de servicio “ Dublin ” nueva
Una vez que ha generado el proyecto, puede concentrarse en la implementación del servicio de flujo de trabajo WCF con las diversas técnicas descritas anteriormente en este artículo. La experiencia del diseñador de flujo de trabajo nueva permite implementar el servicio completo mediante el enfoque de desarrollo de flujo de trabajo de gráficos. Una vez haya terminado de crear el servicio de flujos de trabajo completos, estará listo para implementar el servicio a un servidor Windows habilitada con las extensiones "Dublin".
Puede implementar los servicios en IIS o WAS con cualquier técnica normalmente se utilizan para las aplicaciones Web (puede implementarlo directamente desde Visual Studio si su entorno permite). También puede utilizar los cmdlets de Windows PowerShell para automatizar estas tareas. (Estos cmdlets permiten crear secuencias de implementación automatizadas para los entornos de WCF y WF. Si desea intentar con cualquiera de estos cmdlets, basta con abrir PowerShell de Windows en un servidor de aplicaciones de Windows y escriba Ayuda <command> para aprender a empezar a utilizar ese comando concreto.) Una vez implementado, puede empezar a usar Administrador de IIS para tener acceso a las extensiones "Dublin" varias resaltadas en Figura 8 .
Figura 8 las extensiones de “ Dublin ” en el Administrador de IIS
Implementar aplicaciones con "Dublin"
Muchos entornos no permiten a los desarrolladores implementar servicios directamente en sus servidores administrados por motivos de seguridad y el aislamiento. " Dublin" ofrece una solución alternativa para implementar servicios a través de sus características de importación/exportación de la aplicación.
Puede empaquetar aplicaciones WCF y WF para implementación en otros servidores seleccionando la característica de exportación de aplicaciones de Administrador de IIS. De este modo aparecerá un cuadro de diálogo que le pide que seleccione una aplicación específica para exportar. Una vez que ha especificado una ubicación, al presionar exportar generará un paquete de archivos con una extensión .zip que contiene todo el código WCF y WF así como todos los valores metadatos y la configuración de una sola aplicación. A continuación, se puede mover y importar en otro servidor a través de las extensiones "Dublin" este paquete. Ahora puede enviar el archivo .zip para el profesional de TI que administra los servidores y dejar que simplemente le tenga cuidado de ella.
El cmdlet de Windows PowerShell Export-aplicación realiza lo mismo. Esta capacidad de exportar la aplicación también es muy útil para entornos de prueba y validación del sistema.
Puede importar una aplicación WCF y WF activando la característica de importación de aplicación o mediante el cmdlet Import-Application (también puede ver el contenido de un paquete mediante el cmdlet Get-PackageManifest). La característica de importación, a continuación, le pedirá que para seleccionar el paquete (archivo .zip) que desea importar.
Durante el proceso, puede especificar el nombre de aplicación, el grupo de aplicaciones y la ruta de acceso física de la aplicación, si lo desea. Y dado que "Dublin" proporciona configuración centralizada de persistencia, al implementar los servicios de flujo de trabajo a otro servidor, no necesita preocuparse acerca de cambiar la configuración de persistencia en el nivel de aplicación. Simplemente va utilizar la nueva base de datos de persistencia asociado con el nuevo servidor. Estas características simplifican el proceso de implementación de aplicaciones WCF y WF en un entorno de servidores sea muy accesible para el administrador del sistema responsable de las tareas.
Una vez que ha implementado correctamente una aplicación, puede empezar a configuración de los servicios a través de las otras extensiones proporcionados por Dublin. Por ejemplo, en algunas situaciones, el administrador del sistema que tenga que manualmente volver a configurar la configuración de tiempo de ejecución para la persistencia y seguimiento de las bases de datos. Con las extensiones "Dublin", esto es bastante sencilla. Simplemente seleccione servicios de la vista predeterminada y, a continuación, verá una lista de todos los servicios administrados, junto con un panel derecho que expone diversas opciones de configuración de servicio (consulte la figura 9 ). Estas opciones permiten cambiar fácilmente la configuración de persistencia, configuración de seguimiento y otras opciones WCF relacionadas con la seguridad y el límite. Y nunca tiene que tocan un archivo de configuración de WCF.
Figura 9 ver y configurar servicios con las extensiones de “ Dublin ”
Hay varios cmdlets de Windows PowerShell para realizar estas tareas, incluidos el ServicePersistence-Get, Set-ServicePersistence, Enable-ServiceTracking y Get-TrackingParticipant. Esto significa que es mucho más fácil de automatizar la instalación y configuración de un entorno de servidor de aplicaciones.
Administración de aplicaciones en ejecución
Durante el ciclo de vida de una aplicación, los desarrolladores y administradores de sistemas necesitan la capacidad para supervisar el estado de la aplicación, identificar y ver instancias de flujo de trabajo problemático y para terminar de ellos cuando sea necesario. " Dublin" proporciona varias extensiones destinadas a estas necesidades de administración comunes.
Si selecciona la opción instancias almacenado en el Administrador de IIS (vea figura 8 ), que tendrá que realizar para una vista de panel que proporciona una introducción de las que se está ejecutando instancias de flujo de trabajo que han se conserva y potencialmente suspendido (consulte la figura 10 ). El cuadro de información general sobre muestra el número total de las aplicaciones y servicios implementados en el servidor, sitio o aplicación (en función del ámbito seleccionado).
Figura 10 ver almacenan las instancias de flujo de trabajo
El cuadro de instancias de almacenado muestra un resumen de las instancias de flujo de trabajo almacenado y en ejecución, llamada fuera de los que puede bloquearse o suspendido (lo que significa que se finalizó un error). Dado que las instancias de suspensión son los que los usuarios normalmente tendrá que tratar directamente, proporcionan varios cuadros que facilitan aislar las instancias suspendidas específicas basadas en ruta de acceso virtual, nombre de servicio o tipo de excepción.
Hacer clic en cualquiera de los vínculos (que se muestran en azul) para mostrar la lista de instancias almacenadas y para ver sus detalles. En este momento, puede suspender, finalizar o anular las instancias de servicio manualmente seleccionando las acciones muestran en el panel derecho (consulte la figura 11 ). Suspender una instancia de servicio detiene la ejecución de la instancia e impide que se recibir nuevos mensajes. Instancias suspendidas más adelante se pueden reanudar, momento en que empezará recibir mensajes de nuevo. Terminar una instancia de servicio detiene la ejecución de la instancia y quita, el almacén de persistencia, lo que significa que no se puede reanudar. Por último, anulando una instancia de servicio borra el estado de la memoria que pertenecen a la instancia especificada y recuperará el último punto persistente (que se almacena en el almacén de persistencia).
Figura 11 ver instancias almacenadas individuales
Los cmdlets de Windows PowerShell Get-ServiceInstance y Stop-ServiceInstance ofrecen funciones equivalentes desde la línea de comandos; proporcionan numerosas opciones de línea de comandos para identificar las instancias de servicio específico.
Actualizar aplicaciones en ejecución
Uno de los aspectos especialmente molesto de trabajar con los sistemas reales es la necesidad de actualizar periódicamente. Para aplicaciones distribuidas más complejas, esto puede ser complicado hacer correctamente cuando los cambios necesarios requieren actualizaciones a la base de datos lógica empresarial y código del servicio al mismo tiempo. Normalmente, no es posible aplicar actualizaciones importantes de forma atómica a medida mientras se ejecuta la aplicación.
Uno para enfocar este problema consiste en poner la aplicación fuera de conexión mientras se realiza la actualización. Sin embargo, si realmente piensa sobre él, no hay una fácil manera para tomar una IIS y WAS aplicaciones sin conexión al realizar una actualización de un sitio Web de simultáneamente. Esta es otra área donde las extensiones "Dublin" agregar valor a través de una característica sin conexión simple.
Puede seleccionar una aplicación en el Administrador de IIS y, a continuación, seleccione el comando deshabilitar protocolos en el panel derecho que se muestran en la figura 8 (es importante tener en cuenta que esto es probable que se cambiará en una versión posterior). Esto hace que todas las instancias de servicios de la aplicación para finalizar en un estado bloqueado o para finalizar su ejecución Naturalmente, sin permitir cualquier las de solicitudes entrantes nuevas a procesarse mientras tanto.
En este momento ha básicamente dejado el flujo de mensaje para esta aplicación, lo que significa que los clientes no podrán enviar mensajes a servicios sin recibir errores (en que no se cola hasta que de lo contrario serían en BizTalk Server). La forma de este método funciona en segundo plano es bastante sencilla: la extensión "Dublin" simplemente quita todos los controladores de protocolo para esta aplicación concreta y se guardan para que fácilmente se pueden restaurar una vez terminado con la actualización.
Una vez que la aplicación esté sin conexión, puede realizar cualquier actualizaciones son necesarios. Cuando terminado con las actualizaciones y está listo para poner la aplicación de nuevo en conexión vuelva a, a continuación, puede seleccionar el comando de restauración de protocolos. Windows PowerShell deshabilitar-ApplicationMessageFlow y los cmdlets Enable-ApplicationMessageFlow también se puede utilizar para realizar estas mismas tareas desde la línea de comandos.
Supervisión de aplicaciones en ejecución
Las empresas necesitan también la capacidad de supervisar aplicaciones en ejecución para ver cómo funciona el negocio y qué cambios es posible que sea necesario. Los runtimes WCF y WF ya vienen con un integrado, seguimiento de infraestructura que las extensiones "Dublin" se basan en, facilitando la permiten supervisar dentro de las aplicaciones WCF y WF.
Figura 12 configuración seguimiento básico
Hay dos reproductores principales en la 4.0 de Framework .NET arquitectura de seguimiento: los perfiles de seguimiento y seguimiento de los participantes. Los desarrolladores definen perfiles de seguimiento que indican el tiempo de ejecución qué sucesos para seguimiento y, a continuación, seguimiento de los participantes pueden suscribirse a los eventos.
"Dublin" incluye algunos perfiles de seguimiento integrado que facilitan realizar el seguimiento de un conjunto común de eventos útiles. Puede habilitar fácilmente seguimiento para su aplicación desplazándose a un servicio determinado en el Administrador de IIS y seleccionando el seguimiento en el panel derecho.
A continuación, verá el cuadro de diálogo que se muestra en la figura 12 , que permite configurar algunas capacidades de seguimiento básicos de los flujos de trabajo y servicios. Una vez hayas configurado esto, las actualizaciones adecuadas se realizarán en la configuración y la infraestructura de seguimiento WF y WCF se iniciar en.
Si le gustaría, también puede ver datos de seguimiento a través de las extensiones "Dublin". Puede seleccionar ver seguimiento de datos al inspeccionar instancias de servicio almacenado (consulte la figura 11 ), que se ejecutará una consulta SQL en el almacén de supervisión para generar una lista de seguimiento de eventos para ver (consulte la figura 13 ). Cuando desea realizar el seguimiento de eventos personalizados, puede definir perfiles de seguimiento personalizado y configurarlos mediante la opción de perfiles de seguimiento en la vista principal de administrador de IIS.
Figura 13 ver datos de seguimiento
No dispone de espacio para cubrir todas las características de "Dublin" aquí, hay varias otras características atractivas merit más discusión (consulte la barra de lateral de "características adicionales de Dublin" para obtener más información), pero espero una serie de conocimientos más claro de la función de "Dublin" y algunas de las características principales proporcionará.
¿Desde "Dublín" a "Oslo"?
Si ha oído hablar de la plataforma con nombre en código "Oslo", está probablemente pregunte en este momento cómo se relaciona "Dublin" con esa iniciativa. En primer lugar, "Oslo" es una nueva plataforma de modelado siendo desarrollada por Microsoft para simplificar la forma que diseña, crear y administrar aplicaciones distribuidas. La plataforma de modelado consta de tres componentes principales: el lenguaje de modelado "Oslo" (también conocido como " M"), el repositorio de "Oslo" y la herramienta de modelado de "Oslo" Quadrant (en inglés (también conocido como ")"). " Oslo" es realmente una plataforma que otras aplicaciones y tecnologías pueden crear en para simplificar la experiencia del usuario a través de un enfoque controlado por modelos.
Características de “ Dublin ” adicionales
"Dublin" viene con varias otras características que no tiene espacio para cubrir con detalle en este artículo. Pero una pena llamar a cabo es soporte técnico de escala - fuera de las implementaciones a través de conjuntos de servidores que se integran con soluciones de equilibrio de carga existentes, como los de administración de instancias de servicio almacenado en la matriz a través de una base de datos centralizada de persistencia. El error integrados que controla la lógica permite almacenadas las instancias ejecutar en cualquier nodo en el conjunto de servidores e impide que condiciones de carrera cuando varios nodos compiten por la misma instancia.
El otro componente importante es el servicio de reenvío. Este servicio permite interceptar todos los mensajes entrantes para realizar enrutamiento central basado en el contenido de mensaje. En concreto, esta característica proporciona una base interesante para crear soluciones de control de versiones de servicio sofisticados.
"Dublin" también se incluye con varios servicios claves para administrar el ciclo de vida de instancias de servicio incluidos la Server de temporizador duradero y el servicio de reinicio de instancia. " Dublin" también sabe cómo aprovechar el extremo de control de instancia proporcionada por el 4.0 de .NET Framework y el nuevo IIS y WAS característica Inicio automático, que permite iniciar servicios cuando se inicia el equipo en vez de esperar el primer mensaje. Más artículos sobre estas características se pueden aparecen en los próximos meses varios.
"Dublin" será uno de las primera tecnologías para aprovechar la plataforma de modelado "Oslo". Podrá exportar aplicaciones "Oslo" desde el repositorio y fácilmente implementarlos en Dublin, donde puede beneficiarse de las diversas características de alojamiento y administración descritas en este artículo. Uso de modelos para describir y automatizar las implementaciones de aplicaciones parece una victoria para entornos de TI complejos.
Medida los "Dublin" y "Oslo" maduren, es probable que la integración entre las dos tecnologías seguirá creciendo. Microsoft indica su intención de que las dos tecnologías será muy complementarias entre sí.
¿Qué ocurre con BizTalk Server?
Otra pregunta habitual es cómo se relaciona "Dublin" con BizTalk Server. En muchas formas, BizTalk Server animado muchas de las características que se ve en "Dublin" hoy en día. Aunque ambas tecnologías proporciona capacidades de administración similar, hay una gran diferencia entre los dos en términos de su enfoque. " Dublin" agrega extensiones de alojamiento y la administración a Windows Server diseñado específicamente para las aplicaciones WCF y WF, mientras que BizTalk Server se centra en integración de aplicaciones con sistemas que no sean de Microsoft mediante una variedad de formatos de mensaje diferente, transportes y las técnicas de asignación.
El objetivo principal de BizTalk Server siempre ha sido y continuará que la integración con sistemas que no sean de Microsoft (aplicaciones de línea de negocio, los sistemas heredados, RFID dispositivos y protocolos de negocio a negocio). BizTalk Server permanecerá centrado en estas ventajas principales en los años con antelación. En general, deseará continuar utilizando BizTalk Server al que se centró principalmente en estos tipos de escenarios de integración (EAI) de aplicación de empresa.
Sin embargo, puesto que muchas aplicaciones WCF y WF no necesita estos tipos de capacidades de integración, BizTalk Server a menudo puede sentir como excesivo. Se trata con precisión dónde encaja "Dublin" en el, como una alternativa más sencilla que proporciona funciones de administración similar. Al final, "Dublin" será más rentable para estos escenarios de BizTalk Server ya que las extensiones "Dublin" incluirán una parte fundamental de Windows Server y no requieren la comprar los adaptadores de integración que no es necesario. Es probable que una versión futura de BizTalk Server creará en las extensiones "Dublin" para aprovechar las inversiones de administración principales efectúen a Windows Server.
Especial gracias a Eileen Rumwell, Berman Marque esta opción, Dino Chiesa, Fussell Marque esta opción, Ford McKinstry, Marjan Kalantar, acantilado Simpkins, Brown Kent, Horrocks de texto y Wolf Kenny para su útil obtener de ayuda con este artículo.
Aaron Skonnard es cofundador de Pluralsight, un proveedor de formación de Microsoft .NET principal que ofrece dos cursos de formación de duración e impartido por un instructor y conexión. Aaron es el autor de numerosos libros, notas del producto y artículos así como cursos Pluralsight en REST, Windows Communication Foundation y BizTalk Server. Puede ponerse en pluralsight.com/Aaron .