Are service, ServiceLoader, service provider, service locator for distributed systems or collocated?

[Anil Philip]

We live in the Cloud and Spring framework today and it's easy to think of everything as distributed.
But I don't see any mention of it here:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html
Are service, ServiceLoader, service provider, service locator for distributed systems or a single Java application?

[Tim Holloway]

If you'll note in the comments in that link, they are using a serviceloader for graphics. If anything, I'd say serviceloader is more oriented towards local use than cloud use, although that depends on what kind of classloader you use with it.

There are 2 cases I can think of where you may find a serviceloader under the covers in a local app. One is for image services and the other for database persistence services (locating a driver for a JDBC URL type such as "jdbc:mysql"). I did some very deep digging into that last not so long ago, and I'm fairly sure that's what they used, in fact. It's why you don't need Class.forName() when creating a JDBC Connection anymore.

On the image front, I've been overhauling my open-source reciper management application and it can upload images in a variety of formats, so, again, common image logic is served by a service specific to the image format being uploaded. I had to add a new service to the list as part of the upgrade, in fact. A lot of online recipe sites use "webp" as their image format and I was only set up for the old standards like GIF, JPEG, PNG and so forth.

[Stephan van Hulst]

How did you relate ServiceLoader to the Cloud?

[Anil Philip]

Stephan van Hulst wrote:How did you relate ServiceLoader to the Cloud?

I was using Cloud and Spring framework as instances of distributed systems.
If I remember correctly, Kubernetes and Pivotal Cloud Foundry both use services.

[Stephan van Hulst]

"Service" is a very broad term that covers many different things. Pretty much any application uses things that can be described as "services". Those services aren't necessarily the kind of services that ServiceLoader is about.

ServiceLoader is a class that dynamically loads instances of service provider interfaces. You can use it to build plugin systems where you can load classes into your application that weren't available at compilation time.

[Anil Philip]

Tim Holloway wrote:If anything, I'd say serviceloader is more oriented towards local use than cloud use, although that depends on what kind of classloader you use with it.
One is for image services and the other for database persistence services (locating a driver for a JDBC URL type such as "jdbc:mysql").

So Service in Java is no longer like the Java networking (I forget the API name) or even Visibroker CORBA that was used by networked applications?
I wonder if Spring has replaced them.

[Anil Philip]

Stephan van Hulst wrote:You can use it to build plugin systems where you can load classes into your application that weren't available at compilation time.

That is a good use case for it - thanks.

[Paul Clapham]

When Java was extended by classes which could process XML, the Java people threw in some code which could parse XML so that those classes would be useful. But they wrote that code so that it used a service loader to load an XML parser from the classpath. This enabled people to write better XML parsers which could easily be used by people who needed better XML parsing. And when I say "easily" that means you could just take the (properly configured) jar and add it to your classpath and you were ready to go.

[Anil Philip]

Paul Clapham wrote:When Java was extended by classes which could process XML, the Java people threw in some code which could parse XML so that those classes would be useful. But they wrote that code so that it used a service loader to load an XML parser from the classpath. This enabled people to write better XML parsers which could easily be used by people who needed better XML parsing. And when I say "easily" that means you could just take the (properly configured) jar and add it to your classpath and you were ready to go.

@Stefan, Paul, Tim
But couldn't you always do this? just switch out the jar files on the class path to get a new "provider". Unless I am mistaken, I don't know how this is new.

[Stephan van Hulst]

I think you're talking about swapping out JARs and rerunning the application so it uses the new JAR. Sure, as long as the JARs are binary compatible, this was always an option.

That's not the benefit that ServiceLoader brings though. There are two advantages of ServiceLoader that currrently spring to my mind:

First, ServiceLoader doesn't require the classes to be available at link-time. Instead, your application could already be running, then you drop a JAR in some plugin directory and you could hot-load it into your running application.

Secondly, ServiceLoader can load multiple different services that implement the same interface. Your application can simply iterate over all loaded services, and choose which ones it wants to call.

Here is a concrete example:

Say I wrote an image editor that saves rasterized bitmaps to some image file format. It would be a pain to include the code for every possible file format in my application. Instead, I write a Service Provider Interface for serializing an image:

public interface ImageCodec {

  String formatName();

  String formatDescription(Locale locale);

  String fileExtension();

  void encode(BufferedImage image, OutputStream stream) throws IOException;

  BufferedImage decode(InputStream stream) throws IOException;

}

Now I can release the application, and somebody else can write implementations of ImageCodec at a later time. Multiple different JARs containing such implementations can be loaded into my application, and might appear in the drop-down menu of a file saving dialog. The user chooses one, and the application then selects the associated codec to write the image to file.

[Tim Holloway]

Stephan van Hulst wrote:
ServiceLoader is a class that dynamically loads instances of service provider interfaces. You can use it to build plugin systems where you can load classes into your application that weren't available at compilation time.

You can, however, also use ServiceLoader to connect to a selected service from a set of services which are already part of your compiled application. Case in point: The image loader services I am using at the moment. If the service for a given image type wasn't included in the build, it's not going to dynamically seek and load at runtime because the service loader in question wasn't designed to do that.

JDBC, on the other hand, uses a classpath scanner to locate the meta-data that links a given URL to its corresponding Driver and configures its serviceloader accordingly and it does support loading classes that weren't compiled in. The JavaDocs for ServlceLoader allude to such a process where they talk about inspecting potential providers. Said providers can be either compiled-in, or added to the runtime classpath as JDBC Driver jaars often are. The standard classloader won't make a distinction.

Anil Philip wrote: But couldn't you always do this? just switch out the jar files on the class path to get a new "provider". Unless I am mistaken, I don't know how this is new.

.

No, that gives you no choice of providers, only the one you hard-wired into the app at build time. Going back to my image processing example, I am certainly not going to build one version of the webapp for JPEGs, another for GIFs, etc. The app uses a file chooser to locate an image file, then the service locator to load it, based on the detected image type.

You may be confusing Service Loader with Inversion of Control (IoC) mechanisms such as Spring. Spring allows you to wire together selected components at build time, but it does not alter the wiring at runtime. Service Loader, is in fact, a variation of IoC's opposite: the Service Locator design pattern.

[Paul Clapham]

Anil Philip wrote:But couldn't you always do this? just switch out the jar files on the class path to get a new "provider". Unless I am mistaken, I don't know how this is new.

No. In the case I described, you have the option to put a jar file in the classpath which replaces code which is built into the JRE. You are describing a design where a feature is always provided via a jar file.

[Anil Philip]

Tim Holloway wrote:
You may be confusing Service Loader with Inversion of Control (IoC) mechanisms such as Spring.

No, I was thinking of Java Microservices where there are SpringBoot servers on different machines (servers).
Each Microservice handles a different functionality.
The services have to be looked up somehow.
I was wondering if this was the mechanism (ServiceLoader, service provider, service locator).

[Anil Philip]

Stephan van Hulst wrote:I think you're talking about swapping out JARs and rerunning the application so it uses the new JAR. Sure, as long as the JARs are binary compatible, this was always an option.

That's not the benefit that ServiceLoader brings though. There are two advantages of ServiceLoader that currrently spring to my mind:

First, ServiceLoader doesn't require the classes to be available at link-time. Instead, your application could already be running, then you drop a JAR in some plugin directory and you could hot-load it into your running application.

Secondly, ServiceLoader can load multiple different services that implement the same interface. Your application can simply iterate over all loaded services, and choose which ones it wants to call.

Thank you! It helps.
Anyone studying for the OCP from the Boyarsky book could benefit from this explanation.
If ServiceLoader, service provider, service locator are meant to be local then I assume Java Microservices would use a different mechanism. (my reply to Tim above)

[Tim Holloway]

Well, if each service runs under a different microservice, then what you really need to do isn't call a different service within the front-end using ServiceLocator, you need to have the front-end be a dispatcher to invoke those downstream services. They'd be running in separate JVMs (assuming that they were even in Java at all!) and thus a ServiceLocator could be only of limited use, if at all.

It's not so much about being literally cloud-based as it is about the difference between running everything in a single JVM process or not. You could even have 4 different microservices running as separate webapps within a single copy of Tomcat with the front-end also being a webapp in the same or different instance of Tomcat).

A rough parallel would be how I have almost all my public webapps proxied by Nginx. The actual webapps are in different languages on different physical machines, often within containers, but a single instance of Nginx is the place where they all get seen by the outside world. The server farm isn't a cloud, by the effect is the same.