Hello,

We want to call the a service on IS dynamically according to the service name. We want this because in our proecsses, the main process service will call the function services according to some conditions. We usually do this using BRANCH steps, but it will need to change the main process service when we need to add some new functions and new conditions.So we want to config the function services and conditions in a table, and call this service dynamically in the main service.

I notice there is service “wm.EDIINT.util:spawn” can carry out this function, but this service seems could not be copied to other folders, and we didn’t have the WmEDIINT on all of our servers. So any one has this experience? Thanks a lot!

Gordon,

You will need to create a simple java service that accepts the name of a service to be invoked and a document called “inputs” under which any inputs to the service will be mapped.

Search wMUsers for both “doInvoke” and “doThreadedInvoke” for more discussion on this topic.

HTH,

Mark

Being able to invoke services “dynamically” is a powerful feature.
You might be creating an unnecessary security flaw here…

Philip

What security flaw might be created? Invoking a service directly from a FLOW step vs. via the Java API using doInvoke are equal from a security standpoint AFAIK.

The authenticated user associated with the invoking service must also have authorization to execute the dynamically invoked service. Such authorization is controlled by the ACL assigned to the invoked service.

As the ability to invoke a Flow or Java service is a core part of IS’s Java API, I fail to see the additional security concern.

Mark

Thank you all, I have gotten a sample Java service. But I don’t know if there are some hidden troubles. Would you please share your successful experience and the Flow or Java to me? Thanks a lot!

My experience is that the sample service shown in this post works well when you need to invoke a Flow or java service in which the name of the service (and any inputs) are determined at runtime.

Mark

Thank you Mark. It will be very usefull for me.

I am always leery of this type of service where service name is taken as service level input parameter and will be invoked regardless. Yes, setting up proper security implementation should take care of it.
My concern is as below…
Let’s say a service will read from a properties file or database to pick up a service name to invoke. What happens if someone changes this config parameter to shutdown service? Extra care needs to be taken so that this data is protected as well as IS is.
Service could be invoked in variety of ways. (HTTP. FTP, WS, scheduled task, trigger, etc). Let’s say trigger will invoke this service. Someone could publish a document with harmful service name instead and it will be invoked. I believe triggers run with Admin privilege. Certainly, extra considerations need to be made to make sure that all possible scenarios are covered compared to the “normal” code-based invokes.
The main purpose of doInvoke service is to allow access/invoke other IS services within java service code, rather than to allow dynamic invoke of services by taking in arbitrary string as service-level input parameter.

Of course, this is just my opinion.

Philip

Good points Philip. Care should be taken to avoid these when there is a risk. The PSUtilities.misc:invoke and invokeAndCatchErrors shows a way to limit which services can be dynamically invoked.

Virtually every project I’ve worked on has some framework for invoking services dynamically. It hasn’t been an issue (security by obscurity) but diligence is probably warranted.

Here’s another issue that will cause one to lose sleep–if you don’t implement SSL on the Broker, anyone can anonymously shut it down by simply publishing the right document to it. If your Broker is accessible from the 'net for some reason, anyone on the planet can shut it down. Fun, eh?

Phillip,

What alternative do you offer for situations in which the name of the service must be derived or determined programmatically? I’m sure you’re not suggesting that every service name must be hardcoded into the Flow or that the only good option is to use BRANCH statements to reach static INVOKE statements.

An example to consider. The default SOAP processor is very limited in functionality and in its ability to determine the name of a service to invoke based upon the qualified name (QName) of the first element inside the body of the SOAP request. In IS releases up to and including 6.5, adding the ability to perform basic soap message pre-processing to support WS-* standards requires creation of a custom soap processor.

The custom processor has to do some work and then invoke the appropriate service. If you are happy to always use the lookup the service name based only on the namespace name and local name populated in the service’s universal name properties then you don’t need any external repository. However, if you need a more sophisticated algorithm to determine the service name, then the basic universal name registry won’t suffice and its quite possible that the rules for deriving the service name will require some type of external configuration store (file, database table, metadata repository, etc.).

Another example, in some scenarios certain service consumers must be authenticated using LDAP while other consumers require use of a service that calls back to the sender and still other consumers can be authenticated using only basic username and password. Consumers may migrate from one authentication approach to another as they adopt the enterprise’s identity management approach.

The rules to determine which authentication routine to use are configured externally as are the names of the services which perform each type of authentication. A common specification is used to ensure consistency across these pluggable authentication services. Could this be done without using a dynamically derived service name, probably, but not nearly so elegantly and at the cost of much more expensive ongoing maintenance.

I would agree that access control needs to be maintained over any configuration files or repositories that contain service names, but this is nothing new. After all, many have been stuffing login credentials and URL’s into config files for years to avoid hardcoding them.

Mark