|
|
This section discusses the service configuration and resource organization capabilities provided by AquaLogic Service Bus. It highlights features that support service discovery and change management. This section is intended for IT deployment specialists who are responsible for configuring services in an SOA. This section includes the following topics:
AquaLogic Service Bus has a robust resource configuration and organization framework for creating, organizing and configuring resources and ensuring semantic integrity between resource dependencies. It provides features to rapidly test, deploy, and, reverse resource configuration updates if required.
AquaLogic Service Bus has a built-in Project Explorer that allows logical grouping of AquaLogic Service Bus entities, allowing developers and administrators to better organize related parts of large development projects. For more information, see Project Explorer in Using the AquaLogic Service Bus Console.
AquaLogic Service Bus resources can be organized into separate projects. Projects are non-hierarchical, disjointed, top-level grouping constructs. All resources (such as services, WS-Policies, WSDLs, XQuery transformations, etc.) reside in exactly one non-overlapping project.
Resources can be created directly under a project or be further organized into folders. Folders may be created inside projects or inside other folders and are similar to directories in a file system, with the project level being the root directory. Descriptions can be added to all projects and folders to further enhance navigation. The following figure shows the project and folder views in the AquaLogic Service Bus Console.
Resources can be moved between projects or folders and can be renamed. Any AquaLogic Service Bus resource, project or folder can be cloned to create a copy of that resource with the specified target identity. Cloning a project or folder copies all artifacts in the project or folder to a different location.
Resources that are located in one project can reference and use resources that are defined in other projects. Dependencies are preserved when resources are renamed and moved. All references to a renamed or moved resource are automatically adjusted. An additional capability of the Project Explorer is the ability to track which resources outside the current folder are referenced by resources residing in it. Viewing these references gives both the location of the referenced resource (in the format of <project name>/<folder name>/<resource name>) and the type of resource referenced. For more information about referenced resources, see Tracking Dependencies.
AquaLogic Service Bus provides a number of capabilities to organize large numbers of resources in the resource cache. The resources in the AquaLogic Service Bus resource cache include WSDLs, XML Schemas, XQueries, XSLTs, MFLs, WS-Policies, Business Services, and Proxy Services. AquaLogic Service Bus relies on user-configured metadata for resources and services to determine how to process messages.
AquaLogic Service Bus is focused on supporting a set of trusted IT department specialists who manage the resources and services in the resource cache on behalf of the organizations they represent. All such users are defined as integration administrators or integration deployers and have full permissions to modify all the resources in the resource cache. Integration monitor users have full read access to the resource cache but cannot modify any resources. Typically, they are users who search or browse for resources or services. Integration operator users have full read access to the resource cache and can only change the operational characteristics of the services.
For more information about AquaLogic Service Bus users and roles, see Security Configuration in Using the AquaLogic Service Bus Console.
One of the most important features of BEA AquaLogic Service Bus is the Change Center, which is key to making configuration changes inside the service bus. The Change Center has the unique ability to lock its current configuration while changes are being made. This lets the service bus continue to receive and process requests for services while configuration changes are being made in the console.
Additionally, changes being made to the configuration will not affect the current configuration until they are “activated.” Once this is done, the changes go live instantly and the service bus immediately uses the new configuration. This way, ongoing changes can be made without disrupting services. For more information on Change Center features, see
If activated changes cause unpredictable, undesirable events, the Change Center also provides the capability to undo any changes made for any session. Task Details provides information on which resource was changed, who changed it, and when. An entire session or individual changes within a session can be rolled back, enabling AquaLogic Service Bus to roll the affected configurations back to the prior state.
For more information on Change Center, see Using the Change Center in Using the AquaLogic Service Bus Console.
Before you make modifications to resources in AquaLogic Service Bus, you must create a session. All modifications are made using the AquaLogic Service Bus Console in a given session.
A session can be considered a sandbox environment in which changes are kept private to the user making those changes. In other words, they are not visible to other concurrent users making modifications. Modifications made in a session are not deployed in the server until the session is activated. Only one session can be active at any time and should only log into the AquaLogic Service Bus Console through one browser.
To compare a resource modified in a given session against the resource that is already deployed to run time, you can temporarily exit the session, view the deployed resource, then reenter the session and view the changed resource. All resources are visible in the session. The view of all resources in a session is called the session view—it is a merged view of the unmodified deployed resources and the resources modified in the current session. Therefore, the session view at any point in time shows the configuration state if the session is activated at that point in time. The view of resources outside any session is the view of the deployed resources.
All individual session modifications, individual session activations, and undo operations for a session are performed in transactions to prevent data loss in the event of a failure. Sessions are persistent and long running—the restart of a server does not result in the loss of active sessions. This means that you can modify the configuration in a single session over a period of days (during which time the server can be stopped and restarted) if necessary. Each user has their own session, and can work in it independently without the need to lock other users out of the system. You cannot activate a session if another user is already in the process of activating their session. If another user is activating a session when you try to activate your session, the Activate button will be disabled and you will have to wait until the other session is activated before you can activate your session. In certain circumstances, the Activate button may not be disabled if you did not refresh the page or if you are directly using MBeans. In this case, you will time out after a short while.
Administrators have permissions to access other user’s sessions and view ongoing changes, make updates in those sessions, or discard them.
For more information, see Using the Change Center in Using the AquaLogic Service Bus Console.
Sessions use an optimistic scheme for conflicts. When you activate a session, the changes you made to resources in that session become visible immediately in other sessions. If you deploy a changed resource that is open in another user’s active session, the other user’s session receives a message in the Change Center indicating that the deployed resource has changed in the run time since the user started modifications. The user of the active session can then:
For more information, see Using the Change Center in Using the AquaLogic Service Bus Console.
The system keeps a log of all users who activated a session along with any resource modified by the session and when it was modified. This provides the enterprise with auditing and tracking facilities in addition to a history of changes made to a particular resource or project. The log is visible in the Change Center in the AquaLogic Service Bus Console.
A crucial part of managing a large number of resources is establishing and exploring dependencies between resources. For example, it is useful to identify the WSDL that a service implements, or the XQueries used by a message flow configuration. AquaLogic Service Bus provides this capability by automatically tracking the references between resources and creating a graph of the dependencies. In both session views and deployed views, the AquaLogic Service Bus Console displays for a given resource:
Also, for each project and folder, the AquaLogic Service Bus Console displays other resources outside the project or folder that reference resources in the selected project or folder. The AquaLogic Service Bus Console also displays the resources that a given project or folder references. This aids dependency tracking—you can easily navigate the dependency graph in the AquaLogic Service Bus Console by clicking on the names of the referenced resources.
You can use this functionality to identify the dependencies between departmental projects or between departmental projects and corporate-wide shared projects in the resource cache.
Dependencies are preserved when resources are renamed and moved. All references to a renamed or moved resource are automatically adjusted.
AquaLogic Service Bus protects the integrity of all resources in the session view. You can view a list of all current validation errors for all resources in the session view by clicking the View Conflicts link in the Change Center. Changes to a referenced resource can cause validation errors in any resources that reference it.
AquaLogic Service Bus allows you to create resources with most semantic errors. However, all such errors must be fixed before a session can be committed.
There are certain classes of validation errors that are never allowed. If you attempt to update a resource that has one of these disallowed validation errors, your update will fail. For example, where your configuration requires an XQuery, you cannot enter arbitrary text in place of the XQuery. If you try to do this, your update fails. The XQuery and XPath editors in the AquaLogic Service Bus Console provide a facility to validate your expressions. Click Validate to validate your XQuery and XPath expressions at design time. This reduces the possibility of run-time errors as a result of invalid configurations.
You can undo tasks that you have performed in your AquaLogic Service Bus configuration during your current session, and you can undo session activations outside of a session.
If you are working in a session, you can view a list of the modifications you have made in the session by accessing View Changes in the Change Center. You can undo specific tasks in the Change Center. An undo operation can result in objects becoming semantically invalid. For example, if a WSDL operation name change is undone, the proxy service routing to that operation on the service that uses that WSDL is semantically invalid. These validation errors are displayed immediately in the Change Center when you click the View Conflicts link.
Although you can undo tasks in any order (provided that individual undo operations result in valid data), the resulting configuration may be different depending on the order of undo. The undo operation sets the value of the resource to the value it had before the change to that resource. If the task being undone was one that created an object, there is no previous state to which an object can be returned—in other words, no object existed before this task was performed. Effectively, the undo operation deletes the new object from the session. In this case, errors occur for the objects that reference the one being deleted. You can view such errors on the View Conflicts page in the Change Center.
When you are not working in a session, you can view a list of session activations by accessing View Changes in the Change Center. You can undo a session activation in the Change Center. When you undo a session, the session activation is undone and all the operations performed in the session are lost. The system does not allow you to undo a session activation if an error in the run time configuration would result from the undo operation. For example, if you attempt to undo a deployment that removes an object that is being referenced by another object, that undo operation is disallowed. For more information, see “Undoing a Task” in Using the Change Center in Using the AquaLogic Service Bus Console.
Universal Description, Discovery and Integration (UDDI) registries are used in an enterprise to share Web services. Using UDDI services helps companies organize and catalog these Web services for sharing and reuse in the enterprise or with trusted external partners.
A UDDI registry service for Web services is defined by the UDDI specification available at:
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3
UDDI registries are based on this specification, which provides details on how to publish and locate information about Web services using UDDI. The specification does not define run-time aspects of the services (it is only a directory of the services). UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.
Publishing a service to a registry requires knowledge of the service type and the data structure representing that service in the registry. A registry entry has certain properties associated with it and these property types are defined when the registry is created. You can publish your service to a registry and make it available for other organizations to discover and use.
Proxy services developed in BEA AquaLogic Service Bus can be published to a UDDI registry. AquaLogic Service Bus can interact with any UDDI 3.0 compliant registry including AquaLogic Service Registry.
AquaLogic Service Bus' Web-based interface to AquaLogic Service Registry makes the registry accessible and easy to use.
UDDI offers several benefits to IT managers at both design time and run time, including increasing code reuse. UDDI also provides benefits to developers, including the following:
BEA AquaLogic Service Registry is a version 3 compliant UDDI registry certified to work with AquaLogic Service Bus. It is not provided with AquaLogic Service Bus.
For information about AquaLogic Service Registry, see the product documentation at the following URL:
The AquaLogic Service Bus Console makes the AquaLogic Service Registry or any version 3 UDDI-compliant registry accessible and easy to use. In working with UDDI, AquaLogic Service Bus promotes the re-use of standards based Web services. In this way, AquaLogic Service Bus resources can be searched for and discovered and used by a wide and distributed audience. Web services and UDDI are all built on a set of standards, so re-use promotes the use of acceptable, tested Web services and application development standards across the enterprise. The Web services and interfaces can be catalogued by type, function, or classification so that they can be discovered and managed more easily.
Permissions in BEA AquaLogic Service Registry were developed so that administrators can manage users' permissions in BEA AquaLogic Service Registry and create views into the registry, specific to the needs of the different user types. User permissions set in AquaLogic Service Bus govern access to the registries, their content, and the functionality available to you.
You can use the AquaLogic Service Bus Console to publish proxy services to AquaLogic Service Registry. You can publish all proxy services to a UDDI registry—this includes the following service types: WSDL, Messaging, Any SOAP, and Any XML. For information on how to publish proxy services to a UDDI registry, see “Publishing a Proxy Service to a UDDI Registry” in System Administration in Using the AquaLogic Service Bus Console.
You can import services from the registry as AquaLogic Service Bus business services. The service types supported are WSDL services with SOAP over HTTP binding and AquaLogic Service Bus proxy services (used primarily in multi-domain deployments). For information on how to import business services to AquaLogic Service Bus, see “Importing a Business Service from UDDI Registry” in UDDI in Using the AquaLogic Service Bus Console.
Service definitions in AquaLogic Service Bus can be automatically synchronized (both ways) with those in UDDI. Services can be automatically published to a UDDI registry after they are created or changed within AquaLogic Service Bus and business service definitions can be imported from UDDI and automatically updated when the original service is changed in UDDI. Alternatively, you can configure the AquaLogic Service Bus Console to prompt you for approval for synchronization when a service changes in the UDDI registry. For more information, see "Configuring a UDDI Registry" in UDDI in Using the AquaLogic Service Bus Console.
http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm
http://uddi.org/solutions.html
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm
|