Uso de los calificadores de Quality of Service en WebSphere Integration Developer V7, Parte 1

Administración de las transacciones y de la seguridad en sus aplicación empresarial

Este artículo habla sobre cómo usted puede utilizar eficientemente los calificadores de Quality of Service provistos por WebSphere Integration Developer V7 a fin de administrar las transacciones, asegurar las aplicaciones y realizar llamadas c onfiables en una aplicación empresarial.

Samanvitha Kumar, Staff Software Developer, IBM

Photo of the author, Samanvitha KumarSamanvitha Kumar trabaja como Staff Software Engineer en el IBM India Software Lab. Es IBM Accredited IT Specialist (aplicaicones empresariales) y actualmente forma parte del equipo de WebSphere Commerce Development. Samanvitha tiene 5 años de experiencia en la industria y ha trabajado extensamente en el espacio de Master Data Management and Business Integration. Ha publicado ´varios artículos en el dominio de business integration.


Nivel de autor contribuyente en developerWorks

Pramodh Ramesh, Software Engineer, IBM

Photo of Pramodh RameshPramodh Ramesh trabaja en las Soluciones Industriales en el IBM India Software Lab. Ha estado trabajando con varios clientes en diferentes empresas industriales, tales como Bancos, Telecomunicaciones y Minoristas. Actualmente está desarrollando estructuras para proveer soluciones end-to-end para la Industria Bancaria. Su fuerte incluye la administración de la integración y de los procesos empresariales basándose en la arquitectura orientada a los servicios.



21-01-2011

Introducción

El panorama de empresas de IT es altamente complejo porque se requieren varios sistemas para distintas operaciones. Lograr la integración continua entre estos sistemas con la auida de las aplicaciones empresariales es importante.

WebSphere Integration Developer (de aquí en adelante denominado Integration Developer) es un herramienta de autoría que lo ayudan a usted a componer aplicaciones empresariales complejas basadas en sus requisitos. Provee una forma sencilla de lograr los requisitos críticos funcionales y no funcionales, sin necesidad de programación o de ningún cambio en el código de implementación de los servicios por medio de calificadores. Los calificadores son especificaciones de Quality of Service (QoS) que definen un conjunto de características de comunicación requeridas por una aplicación para la prioridad de las transmisiones, el nivel de confiabilidad de la ruta, la administración de las transacciones y el nivel de seguridad.

Los calificadores definen cuánta administración debe ser provista para un componente en tiempo de ejecución. Propagan las transacciones y controlan la calidad y la entrega oportuna de los mensajes. Puede usar calificadores para ampliar la calidad del servicio a los componentes ayudando a abordar el manejo de los errores y los requisitos en cuanto a la carga y a la performance de los servicios empresariales.

Esta serie de artículos que consta de dos partes tratará todos los calificadores de QoS provistos por el Integration Developer. Hemos elegido el Integration Developer V7.0 a los fines de este artículo ya que es le versión más reciente y les da soporte a 13 tipos diferentes de calificadores. La Parte 1 del presente artículo se concentrará en 6 de ellos, los que tratan la validación de las transacciones, de la seguridad y de los datos. Brindará la descripción, los valores aplicables y los posibles escenarios para cada uno de los calificadores a fin de ayudarlo a comprender cuál utilizar en su aplicación empresarial.


Comprender los calificadores

Los calificadores de Quality of Service están especificados en el editor del ensamble en el Integration Developer y pueden estar basados en:

  • Interfaces: Éstas especifican los calificadores soportados por un servicio destino y representan un contrato entre un servicio y el cliente.
  • Referencias: Éstas especifican la confiabilidad de las invocaciones asincrónicas y si los métodos de los componentes destino deberían se federados como para de la transacción de cualquier cliente.
  • Implementaciones: Éstas son utilizadas para identificar la autoridad de los servicios y expresar sus requisitos para un entorno transacciones.

La siguiente es la lista de todos los calificadores provistos por Integration Developer V7.0. Este artículo describe los primeros seis:

  1. Transaction qualifies
  2. Join transaction qualifier
  3. Security identity qualifier
  4. Security permission qualifier
  5. Suspend transaction qualifier
  6. Data validation qualifier
  7. Activity session qualifier
  8. Asynchronous invocation qualifier
  9. Asynchronous reliability qualifier
  10. Event sequencing qualifier
  11. Join activity session qualifier
  12. Store and forward qualifier
  13. Suspend activity session qualifier

Por omisión, el Integration Developer genera algunos calificadores para proveer el manejo de las transacciones y la entrega confiable de los mensajes asincrónicos. Usted puede editar estos valores predefinidos en el diagrama del ensamble basándose en sus necesidades empresariales. Para ver y editar los calificadores utilizados en un módulo:

  1. Right-click an empty portion of the canvas and select Show In > Properties View.
  2. Click the All Qualifiers tab, where all of the qualifiers defined in the module are displayed as shown in Figure 1.
    Figure 1. Viewing qualifier settings
    Figure 1. Viewing qualifier settings

Transaction qualifier

A transaction is a unit of activity within which multiple operations on data can be made atomic (indivisible), such that exactly all or none of the actions are made permanent. The transaction qualifier is used to define a logical boundary or unit of work, such that either all or none of the changes made by the components falling within this boundary are committed or rolled back as a single unit. This is used when a set of operations are dependent on each other, mandating that either all are completed successfully, or all are rolled back even if one of them fails.

Applied on: Implementation

Applicable values: As shown in Figure 2, the transaction qualifier can have any of the settings below, depending on the design of the business application:

  • Global: A global transaction is a unit of work in a distributed transaction processing environment in which multiple resource managers may be enlisted. Things to note in a global transaction are:
    1. If the client propagates a transaction and a component is configured to join that transaction, then this component will run under the same transaction. In other words, resources updated by the component are committed when the client commits the transaction.
    2. If either of these conditions is missing, the component runs under a new global transaction that is committed when the operation completes.
  • Local (default): This setting is required when a component implementation is not capable of participating in a two-phase commit protocol. Things to note in a local transaction are:
    1. Even if the client propagates the transaction and the transaction qualifier is set to local, then the component runs in a local transaction because running the business logic in a local transaction performs better than in a global transaction in certain scenarios.
    2. Local transactions are not propagated to services invoked by the component.
    3. The local transaction joins an activity session if one is active. If an activity session is not currently active, one is started automatically.
  • Any: If a global transaction context has been propagated from the client, the runtime environment will dispatch methods from the component in a global transaction. Otherwise, the runtime environment will establish a local transaction environment.
  • Local application: Use this qualifier in scenarios where the application holds the responsibility for managing the transactions. Selecting this option is equivalent to setting the transaction descriptor to Not Supported and setting the LocalTranResolver to application for an enterprise Java™ bean.
Figure 2. Possible values of the Transaction qualifier
Figure 2. Possible values of the Transaction qualifier

Scenario

Consider a case where you have an SCA component that provides certain important operations and needs to be part of a global transaction due to the business need. In such a case, you will set the transaction qualifier on the implementation of this component to “global”. In some cases, you may also set it to “local” if the operations are better off if executed in a local environment, rather than using a global transaction that was propagated to it. The behavior of the components depends on the combination of the settings done for the transaction and join transaction qualifiers as explained below:

  • If the caller transaction qualifier is set to "global" and the called one interface joins the transaction, the called one executes under the same global transaction.
  • If the called one qualifier is set to "local", then the called one executes in a local transaction. In such scenarios, a join transaction cannot be set to "true" on the called one interface.
  • If the join transaction qualifier is set to "false" on the called one and the transaction qualifier is set to "global", a new global transaction is started.
  • If the transaction qualifier on the called one is set to "local", then the transaction is not propagated to the service invoked by it.

Join transaction qualifier

This qualifier determines whether the target service is capable of joining a client-propagated transaction. Since transactions can be propagated only during synchronous invocations, the join transaction qualifier is applicable only when a client invokes a service synchronously.

Applied on: You can apply the qualifier at three levels of a component or import:

  • All of its interfaces
  • An individual interface
  • An individual operation of an interface

Applicable values: You can set the join transaction qualifier to either “true” or “false”, depending on the business need. If set to:

  • True: The component joins a transaction propagated by its caller, if it happens to run in a global transaction.
  • False: The component does not join a transaction propagated by its caller.

Scenario

Consider an enterprise that is using an ERP system for maintaining the HR related information (HR Services) and another ERP for information related to payroll (Payroll Services). In this scenario, the business flow is to create an employee record that involves creating a record in the HR system as well as in a Payroll system. For a successful completion of the application, it is necessary for the records to be created in both systems, as shown in Figure 3.

Both the modules have Java implementations that have been coded to create records in the HR and Payroll systems, respectively. Ideally, you will use the respective adapters while connecting to such enterprise systems. The Java approach has been used for demonstration purposes only.

Figure 3. Assembly diagram for join transaction scenario
Figure 3. Assembly diagram for join transaction scenario

Given the above use case, it is evident that a record needs to be created in both the systems only if both operations are successful. This brings us to the concept of a transaction where, all or none of the changes made by participating operations need to be made permanent. In other words, we know that if any of the two operations fail, the entire transaction has to be rolled back. Hence, both these operations need to participate in a “transaction”.

To achieve this, use the “join transaction” qualifier on the HR and Payroll modules. By setting this value to “true”, you are ensuring that both the components participate in the global transaction propagated by the CreateEmployee module as shown in Figure 4. Consider the case where the HR module succeeds while the Payroll module fails (maybe due to insufficient data, incorrect data, network issues, and so on). The changes made by the HR transaction are also rolled back.

Figure 4. Setting join transaction qualifier on the interfaces
Figure 4. Setting join transaction qualifier on the interfaces

Note: The “join transaction” qualifier also needs the transaction qualifier to be set on the implementation to a value of “global” or “any” as a prerequisite. If the transaction is set to “local”, this generates an error (CWSCA8018E: The joinTransaction qualifier defined on the interface and the transaction qualifier on the implementation do not match) as these two settings are incompatible. In other words, it is not possible for a component to join a transaction that happens to be local in nature.


Suspend transaction qualifier

This qualifier determines whether a caller or client will propagate its transaction to the target component during synchronous invocation. This qualifier takes effect in a global transaction only and is ignored when it is a local transaction or if the invocation is done asynchronously. When the caller wants to control a transaction, you use the suspend transaction qualifier. If the caller wants to commit the change, even if the called component fails, set its value to “true”.

Applied on: Reference

Applicable values: You can set the suspend transaction qualifier to either “true” or “false”, depending on the business need. If set to:

  • True: Synchronous invocations occur outside any client or caller’s global transaction. The transactional environment of the target component is not affected by this qualifier.
  • False: Synchronous invocations run completely within any client’s or caller’s global transaction.

Scenario

Consider an enterprise application that has two modules for creating and retrieving the employee information from the HR and Payroll core systems as shown in Figure 5. Here, the CreateEmployee module requires both the HR and Payroll modules to participate in a transaction as explained previously. However, the RetrieveEmployee module is said to be complete even if either of them is successful.

Figure 5. Assembly diagram for suspend transaction scenario
Figure 5. Assembly diagram for suspend transaction scenario

To achieve the above stated scenario, we have used the following qualifier settings on the CreateEmployee module, as shown in Figure 6:

  • Set Suspend Transaction = false on the HRServices reference.
  • Set Suspend Transaction = false on the PayrollService reference.
Figure 6. Setting suspend transaction qualifier on references of CreateEmployee module
Figure 6. Setting suspend transaction qualifier on references of CreateEmployee module

The settings on the RetrieveEmployee module are as shown in Figure 7.

  • Set Suspend Transaction = true on the HRServices reference.
  • Set Suspend Transaction = true on the PayrollService reference.
Figure 7. Setting suspend transaction qualifier on references of RetrieveEmployee module
Figure 7. Setting suspend transaction qualifier on references of RetrieveEmployee module

Note: The join transaction qualifier is still set to true on both the HR and Payroll Service modules. The functionality required by the RetrieveEmployee module can be achieved by setting join transaction = false on the HR and Payroll services interfaces. However, this conflicts with the requirements of the CreateEmployee module. Hence, when the client needs to control a transaction, use the suspend transaction qualifier. When the service provider needs to control it, you will resort to the join transaction qualifier.

Transaction highlighting

The assembly editor provides highlighting to show where a transaction is propagated. Right-click any empty area on the assembly editor canvas and select Show Transaction Highlighting. This displays all the transaction related data as shown in Figure 8.

  • If an element is not highlighted at all, it does not join or propagate a transaction.
  • A thick solid green line around an element and along a wire shows that the element joins a transaction and the wire propagates a transaction.
  • A broken green line indicates that a transaction might be joined or propagated, but the system cannot confirm that will happen. A Java component reference might have a broken line leading to the target service because the system cannot determine if the Java component makes synchronous or asynchronous outbound calls.
  • A dotted line around a component indicates that the component participates in at least one transaction, but it might participate in more than one transaction.
    Figure 8. Transaction highlighting
    Figure 8. Transaction highlighting

Security permission qualifier

Use the security permission qualifier to restrict access to an operation in an interface to a specified set of users or groups.

If the security permission qualifier is specified, the identity of the caller must have the designated role in order to be permitted to call the interface or operation. If no security permission is specified, no permissions are checked and all callers are permitted to call the interface or operation.

Applied on: You can apply the qualifier to three levels of a component or import:

  • All of its interfaces
  • An individual interface
  • An individual operation of an interface

Scenario

Let us consider a scenario where the Payroll Service needs to be secured so that it is accessed only by authorized users. Hence, the service is accessible only to those callers who identify themselves and are authorized. To define security restrictions for operations or the interface as a whole, use the security permission qualifier.

As shown in Figure 9, we have defined the security permission qualifier on the entire payroll service by defining a “Payroll Auth” role. This means that only those callers, who are part of the Payroll Auth role, are allowed to access the service and others will be denied.

Figure 9. Setting security permission qualifier on PayrollService interface
Figure 9. Setting security permission qualifier on PayrollService interface

You can add users to this role by using the Security role to user/ group mapping in the application:

  1. Once the application is deployed, navigate to the particular application under Enterprise Applications in the Administrative Console.
  2. Click your application name and click Security role to user/ group mapping.
  3. Choose the role, namely Payroll Auth, and click Map users to add particular users or Map groups for adding groups.

In our scenario, we are adding a particular user named payrolladmin as shown in Figure 10. You can also add more users, depending on your requirement. This means that any caller who is part of Payroll Auth role can now invoke this service successfully.

Figure 10. Security role to user/ group mapping
Figure 10. Security role to user/ group mapping

Security identity qualifier

The security identity qualifier specifies the identity under which the implementation executes at runtime by providing a logical role name.

If this qualifier is not specified, then the implementation executes under the identity of its caller, or under the hosting container's identity if no caller identity is present. Roles are associated with the identity and the roles dictate if the implementation is authorized to invoke other components.

Applied on: Implementation

Scenario

Let us consider the previous use case where the Payroll service was secured and only users of the Payroll Auth role are allowed access. For the CreateEmployee component to access the Payroll service, it needs to access it as one of the users under “Payroll Auth” role defined by the Payroll service. For defining such run as users, we shall use the security identity qualifier.

As shown in Figure 11, we have defined “Security identity” on the CreateEmployee component by defining a role called “Payroll access”. This means that the CreateEmployee module will run under the identity for a particular user defined to the “Payroll access” role.

Figure 11. Setting security identity qualifier on CreateEmployee implementation
Figure 11. Setting security identity qualifier on CreateEmployee implementation

Similar to the previous case, we need to again set the security role to user/ group mapping in the Admin Console:

  1. Navigate to this application under Enterprise Applications in the Administrative Console. Click the application name and click Security role to user/ group mapping.
  2. Choose the role namely, Payroll access, and click Look up users. Assign a user to this role as shown in Figure 12.

To show a negative case, you can add a user by name of "noauth" to the Payroll access. Again, this role is mapped to more than one user or a group of users.

Figure 12. Adding wrong user to user or group mapping
Figure 12. Adding wrong user to user or group mapping

Additionally, this qualifier also mandates the setting up of the User RunAs roles in the Admin Console:

  1. To complete this activity, open the Administrative Console of the server and navigate to Enterprise Applications.
  2. Click your application name and click User RunAs roles.
  3. Provide the username and password of the user that you want to add to this role. Select the checkbox next to Payroll access and click OK. The new user is added to the required role as shown in Figure 13.
    Figure 13. Setting the User RunAs role
    Figure 13. Setting the User RunAs role

As per the above configuration, the Create Employee component will execute under the identity of “noauth”.

Executing the application

Because the “noauth” user is not part of the “Payroll Auth” role defined by the Payroll Service component, the service access fails with the error shown in Listing 1.

Listing 1. Security Identity qualifier error
 Caused by:
com.ibm.websphere.sca.ServiceRuntimeException: Fail to invoke
[CreateEmployeeImpl.public commonj.sdo.DataObject CreateEmployeeImpl.createEmployee
(commonj.sdo.DataObject)] for component [{Article}CreateEmployee]: caused by:
com.ibm.websphere.sca.ServiceRuntimeException: Permission denied: User noauth is
    not in role:Payroll Auth and does not have permission to invoke the method
at com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.invokeSync
(JavaImplementationHandler.java:473) at
com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMessage
(JavaImplementationHandler.java:195) at
com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.
processMessageWithPCI(MessageDispatcherImpl.java:753)

Since there is a mismatch in the users specified, the execution of the application is not possible. The solution is to make sure that the user specified under the RunAs role matches the required security specification of the service.

In our scenario, add “payrolladmin” to the “Payroll access” role. Figure 14 shows the new mapping under the security role to a user or group mapping. Figure 15 shows the User RunAs role that now contains payrolladmin.

Figure 14. Mapping payrolladmin to Payroll access role
Figure 14. Mapping payrolladmin to Payroll access role
Figure 15. Adding payrolladmin to User RunAs role
Figure 15. Adding payrolladmin to User RunAs role

Also, in case you do not complete the step of setting up the RunAs data, you will get an error at runtime as shown in Listing 2.

Listing 2. Exception thrown due to an empty RunAs role setting
com.ibm.ws.sca.uow.UOWRolledBackException: caused by: com.ibm.websphere.sca.
ServiceRuntimeException: The run-as authentication data is not configured for
    role Payroll access at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage
(ModuleSessionBean.java:348) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.
transactionRequiredActivitySessionNotSupported(ModuleSessionBean.java:315) at
com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.
transactionRequiredActivitySessionNotSupported(EJSLocalStatelessModule_
43132892.java:233) at com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.
transactionGlobalActivitySessionFalse(UOWStrategyImpl.java:311) at
com.ibm.ws.sca.internal.uow.handler.JoinUOWHandler.processMessage
(JoinUOWHandler.java:165) at
com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage
WithPCI(MessageDispatcherImpl.java:726) at
com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage
(MessageDispatcherImpl.java:1167) at
com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process
ManagedMessageImpl.java:834) at
com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processMessage
(ModuleSessionBean.java:153) at
com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.
processMessage(EJSLocalStatelessModule_43132892.java:97) at
com.ibm.wbit.comptest.controller.invocation.impl.AdhocInvoker.
processMessage(AdhocInvoker.java:72) at
com.ibm.wbit.comptest.controller.invocation.impl.Invoker.
managedInvoke(Invoker.java:284) at
com.ibm.wbit.comptest.controller.invocation.impl.Invoker.
invoke(Invoker.java:175)

Thus, from the above two scenarios, we can understand that for the service provider to restrict the access, it can use the security permission qualifier and the client can use the security identity qualifier to run as a particular role.

Note: The service provider and the consumer can be across two different modules or systems as well.


Data validation qualifier

The data validation qualifier ensures that the data passed to an operation matches the XSD types of the operation's input. You can use it to validate instance data from a business object.

Applied on: You can apply this qualifier to three levels of a component or import:

  • All of its interfaces
  • An individual interface
  • An individual operation of an interface

Applicable values: You can set the data validation qualifier to either of the below values, depending on the design and requirements of your business application:

  • Log error and continue (default): If an error is encountered, the error is logged and the requested operation is performed. There is no guarantee that the service can handle data that is not valid, so a runtime error can occur.
  • Throw exception: If an error is encountered, an exception is thrown and the operation is not performed.

Scenario

Consider a component whose responsibility is to retrieve the details of an order, given the order ID as an input. It is possible that there are some constraints with respect to the format of the Order ID element. For example, some applications define constraints such as the maximum length of the element, pattern details, disallowance of alphabets, and so on. In such a case, passing on an Order ID, which does not conform to these standards, will obviously result in a runtime error. This is where you can do a preliminary check by using the data validation qualifier.

As shown in Figure 16, the “RetrieveOrderDetails” BPEL component accepts the Order business object as an input and does the job of fetching order details from an external system. It also performs some additional tasks, such as logging and storing the details for future use. The OrderBO is a business object that has OrderID, Description, and a list of Items.

Figure 16. RetrieveOrderDetails BPEL and OrderBO
Figure 16. RetrieveOrderDetails BPEL and OrderBO

For the above requirement, you can set the data validation qualifier on the interface as shown in Figure 17. You have set the value to “Throw exception” as this is a fatal error and further processing is meaningless without details of an order. The validation is basically done against the definition of the business object that is supplied as a parameter to this interface.

Figure 17. Data validation qualifier
Figure 17. Data validation qualifier

In this example, there is a limit set on the maximum length allowed for the “OrderId” element in the OrderBO, as shown in Figure 18. Other restrictions such as allowable values, minimum length, patterns, and so on can also be set.

Figure 18. Setting maximum length on the OrderID element
Figure 18. Setting maximum length on the OrderID element

An exception is displayed if the input to the Order interface violates the rules setup against the business object. The execution of the process stops as per the qualifier setting and details about the exception are also logged. Consider the case where the OrderID passed is greater than 10 characters in length. In this case, an exception appears as shown in Listing 3.

Listing 3. Exception thrown by the Data Validation qualifier
 [3/2/10 14:44:16:765 IST]
00000054 Core E CWSCA2001E: The SCA message-driven bean returned the following
exception: "com.ibm.websphere.sca.ServiceRuntimeException: com.ibm.ws.bo.handler.
BOInstanceValidationException: wsdl:http://DataValidation_Interface/
OrderInterface:processOrder_._type validation returned the following errors:
    Property: OrderID has error: CWLBN1010E: The value '78458475874' with length
    11 may have at most length 5/n: caused by: com.ibm.ws.bo.handler.
BOInstanceValidationException: wsdl:http://DataValidation_Interface/
OrderInterface:processOrder_._type validation returned the following errors:
Property: OrderID has error: CWLBN1010E: The value '78458475874' with length 11 may
have at most length 5/n".

Note: Usage of this qualifier leads to performance overhead. Hence, avoid overusing this qualifier. This qualifier is useful when a given business object is used in a number of components. In such a case, instead of including code snippets to do this check at each component, enforcing a global standard is easier.


Conclusion

This article showed how and when to use the QoS qualifiers to provide transaction handling, security handling, and data validation. It discussed some sample scenarios where these qualifiers contribute to the performance and the functionality of a business application. Once the advantages and functionality of these qualifiers are clearly understood, they can significantly help you design complex business applications.

Part 2 of this series will describe activity sessions, reliability, and event sequencing qualifiers, along with some sample scenarios.

Recursos

Aprender

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=619205
ArticleTitle=Uso de los calificadores de Quality of Service en WebSphere Integration Developer V7, Parte 1
publish-date=01212011