The developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this blog will no longer be available. More details available on our FAQ.

Service Registry Sagacity

New sample: Node-RED nodes for WSRR

DavidSeager Tags: wsrr node-red ‎ 6,500 Views

I have posted a new code sample, this time some sample nodes for Node-RED.

Sample code showing how to create nodes for Node-RED to connect to a WebSphere Service Registry and Repository (WSRR) server over HTTPS, to do a query, or perform an SLA check and retrieve endpoints.

The source code is also available on Github, and there is a sample flow which does a basic query and SLA check against some sample data.

The nodes use the recently published SOA Transfer Tool, which exposes a NodeJS library to query WSRR. All of the hard work of talking to WSRR is taken care of by the library, so the nodes themselves are quite simple.

Modified on by DavidSeager

Do I really need API Connect? Why is my registry & repository solution not enough?

DavidSeager Tags: api connect wsrr management ‎ 7,901 Views

Posted over on the API Connect blog is the first in a 3 part set of post talking about API Management and SOA Service Management, the differences and similarities, and where API Connect (our API Management solution) can participate.

https://developer.ibm.com/apiconnect/2017/10/10/really-need-api-connect-registry-repository-solution-not-enough/

Looking back on WSRR V6.3

DavidSeager Tags: wsrr support ‎ 7,022 Views

WSRR 6.3 went out of extended support at the end of September 2017 and is now officially retired.

This release added the Websphere Service Registry and Repository Studio application for manipulating models and Life cycles using UML tooling. The Service Discovery feature was extended to Oracle WebLogic Server and JBoss Application Server.

A big change was that the Governance Enablement Profile (GEP) was introduced which contains models, life cycles and support for best practices when governing Services using WSRR. This later spawned a Redbook to inform and educate on the customization (and simplification) of the GEP.

Finally an Advanced LifeCycle Edition offered Integration with Rational Asset Manager.

At the same time (in September 2017) WSRR V8.0 went out of normal support and into extended support for 3 years.

Modified on by DavidSeager

Returning localized messages from modifiers

DavidSeager ‎ 6,743 Views

How do you return a localized message from a modifier, such that clients like the Service Registry Dashboard will display an error message in the language of the user?

It turns out that the key is to use a custom exception class, and in that class, implement the interface ServiceRegistryLocalizedMessage. This interface has a method "getLocalizedMessage(Locale arg0)" which is called to get a localized message for the exception, and the locale passed in is that of the web browser accessing the Dashboard. Here is a sample exception:

public class LocaleException extends Exception implements
       ServiceRegistryLocalizedMessage {
   public LocaleException(String msg) {
       super(msg);
   }
   public String getLocalizedMessage(Locale arg0) {
       if(arg0 != null) {
           return "Error localised for: " + arg0.getDisplayName();
       } else {
           return "Error no locale";
       }
   }
}

Note the exception class must deal with being called with null for the Locale arg0. A modifier could return one of these exceptions, for example below this modifier will always error with this exception when anything is created:

    public ServiceRegistryStatus create(OriginalObject arg0) {
       // always error
       ServiceRegistryStatus status = new ServiceRegistryStatus();
       status.addException(new LocaleException("ERROR"));
       status.setReturnCode(ServiceRegistryStatus.ERROR);
       return status;
   }

Note that the LocaleException is constructed with a plain string which has no localization, in this example of "ERROR". The exception getString() method does return this string by default, although you can override toString() to return some message using the default key.

However this may not be the best idea, because in Dashboard the error is reported like this for english:

The string "ERROR" that the exception is constructed with appears at the top level. The user must expand the details to see the localized message. If the browser is in Spanish then this is shown:

There again you see "ERROR" but a Spanish message. Therefore I recommend putting either an empty string in the exception constructor or something that is language-neutral.

In a real implementation the getLocalizedMessage() method would need to look the message up from some sort of Resource Bundle.

Modified on by DavidSeager

DataPower, WS-Proxy, WSRR subscriptions and multiple SLDs

DavidSeager Tags: datapower wsrr wsproxy ‎ 7,986 Views

The following is about the behaviour of DataPower's Web Service proxy with a WSRR subscription and the out-of-the-box integration. This is not about what can happen if you write custom processing rules, either stand-alone, or you extend the generated flow in the WS-Proxy when using a WSRR subscription.

Recently I set up the DataPower integration as described in the articles Using WebSphere Service Registry and Repository V8 and DataPower V5 for service level mediation policy enforcement. I was using a Web Service Proxy on 7.5 DataPower firmware, using a named query to retrieve the WSDLs from WSRR.

Multiple Service Level Definitions (SLDs)

In this case, rather than having a single SLD on a service version as described in the article, we had two SLDs. There was an interface WSDL which defined the port type, binding and messages and types. Then there were two WSDLs which just defined endpoints, each endpoint had a different service and port name. The endpoint for each WSDL was attached to one SLD, so we ended up with two SLDs with different endpoints.

The named query was returning all the WSDLs; both endpoint WSDLs and the interface WSDL.

Then we had a single consumer set up in WSRR with two SLAs. One SLA went to one SLD and one went to the other SLD. The intention was to use the context identifier on the SLA to set the SLA the request was using, so we set up the consumer ID location and context ID location fields on the SLD.

The client was able to send a request on either SLA by varying the context ID, and kept the consumer ID the same as that what was set on the Application Version we used to consume both SLDs.

Observed behaviour

The behaviour as we saw was that DataPower would pick one of the endpoints and always route to that endpoint, irrespective of what context ID we were using. It seems that DataPower picks one of the endpoints that the operation is available on to route to.

We then added policies to each SLD, first logging policies and then routing policies.

The behaviour as we saw was that all the policies on all the SLDs were applied on the request, irrespective of what context ID we were using. Looking in the gateway SLA Policies panel confirmed this; DataPower listed all the policies we attached to both SLDs in WSRR on a single SLD on the service. The WSRR documentation about the policy attachment API confirms this behaviour; if a policy is attached to an SLD then a standard PolicyAttachment section is returned and no filters are present. This means that all consumers will get the policy behaviour. If a policy is attached to an SLA then a wsmcf:Filter element is present that specifies that the policy is related to a specific consumer or context pair.

We added policies to the SLAs to see if we could select these policies. When we selected one SLA using the consumer and context ID we saw only the policy on that SLA being used. This confirms what the WSRR policy attachment API documentation says.

Conclusion

This means that in the out of the box DataPower and WSRR integration using only the WSRR subscription on a Web Service proxy, all policies attached to any SLDs are always run when a consumer calls the service. Only policies on the SLA from the consumer to the service SLD can be selected using the consumer and context identifiers. And a single endpoint from the WSDL is selected to be routed to.

It is possible to do things like adding custom rules to the processing to do an endpoint look up in WSRR, or perhaps more advanced DataPower coding to apply different policies, but as of yet I have no experience of such things so cannot detail what is possible.

Modified on by DavidSeager

New WSRR article: High Availability caching with Out of the Box WSRR Nodes in IIB flows

DavidSeager Tags: wsrr high availability iib ‎ 7,675 Views

A new article about WSRR and IIB has been posted. Titled "High Availability caching with Out of the Box WSRR Nodes in IIB flows" this documents the build and test of a high availability scenario in an IIB message flow.

Check it out here: High Availability caching with Out of the Box WSRR Nodes in IIB flows

Modified on by DavidSeager

Looking Back On WSRR V6.2

DavidSeager Tags: wsrr lifecycle support 6.2 ‎ 8,251 Views

WSRR 6.2 ended its extended support period on the 30th September 2016, which means the release is officially out of support. Version 7.5 also went out of normal support on the 30th September, but is now available for extended support for 3 years.

Version 6.2 added policy authoring in the Web UI, a WS-I checker for WSDLs, and a service discovery framework for finding services from other app servers. WSRR 6.2 ran on WebSphere Application Server (WAS) version 6. WAS version 7 support was not added until WSRR V6.3.

Version 6.2 was actually the 4th version of WSRR, with 6.0, 6.0.2 and 6.1 coming beforehand, versioned to keep step with the supported level of WebSphere Application Server. There still wasn't an out of the box governance profile shipped with 6.2, the Governance Enablement Profile wasn't added until V6.3. There was only one choice of UI, the Web UI served from /ServiceRegistry.

Along with the other releases, I worked on WSRR 6.2 mostly on the policy attachment editor in the Web UI. This was notable because it was our first feature which used JavaScript in the browser to render policies and Ajax requests to fetch data from the server. Up until that point, everything was using server-side servlets and JSPs to render the pages.

See all about the software lifecycle on the website.

Modified on by DavidSeager

Integrate IBM API Connect and WebSphere Service Registry and Repository

DavidSeager Tags: connect wsrr api ‎ 9,640 Views

A new developerWorks article has been published which describes three strategies to strengthen your environment for the hybrid cloud using WSRR and API Connect. One of the authors is Chris Phillips, software services for WSRR and API Connect.

This article explains how you can use both WSRR and API Connect together, using combined features to get optimum business value and strengthen your business. You learn three strategies for integrating WSRR and API Connect, so you can pick what is best for your applications and your business.

Check the article out here.

API Governance in API Connect

DavidSeager Tags: apim api management governance apic ‎ 11,955 Views

In version 5.0.0.1 of IBM API Connect there is support for SOAP and REST APIs, as there was in v4. But how can you manage, control and govern your APIs using API Connect, if a little bit of control is needed?

Developer organization level

You can set controls on a developer organization to indicate if anyone can join, or if they have to be invited. You can also create multiple developer organizations on a single catalog portal, and only publish APIs to certain developer organizations. This allows you to control which application developers can see an API.

You can also set if developers can invite others, and if so, what level of access they get.

Approvals for subscriptions

You can control whether the API owner has to approve a subscription to a plan within a product, at the level of the plan (inside the product).

If Require subscription approval is enabled, the app developer can sign up but must wait until the API owner approves before the developer can invoke the API.

Catalog publishing controls

You can set which API developers are able to stage, publish and view APIs in each catalog, at a catalog level. You can set whether approvals are required to stage, publish, or other life cycle actions, for an API.

You can also set who can manage policies in a certain catalog.

This lets you set that users in certain roles can view APIs in the catalog, but they cannot stage or publish. You can allow users to stage or publish an API to the catalog, but require those with permissions to approve before the staging or publishing happens. You can also require approval for other life cycle changes, such as Retire or Deprecate.

Role based access

You can define roles, or use existing roles, to define what users can do in the API Manager.

Each role has a variety of permissions which can be toggled, for view and edit/manage permissions.

This is just for version 5.0.0.1, and future versions have added more features.

Modified on by DavidSeager

WSRR and APIC webcast, API Management news round up

DavidSeager Tags: webcast apic wsrr ‎ 8,512 Views

Robert Laird and I did a webcast entitled "Ask the Experts: Soar into the API Economy by Moving Services & Metadata from WSRR to API Connect" recently, and the replay is available online (sign in to the Global Middleware Community is required).