A Service Consumer is any tier of an organization’s systems that calls web services. These services could be implemented by SOAP, REST, XML over HTTP, EJBs, JMS or MQ applications, RMI, RPC, invocation of COBOL programs on a mainframe with 3270 screen-scraping, communication over a custom TCP socket, DCOM, or one of many other client-server technologies that have existed for many years now.
For our purposes, we are mainly focused on SOAP, REST, maybe XML over HTTP(S). I believe this is what most people mean when they are referring to Web Services.
I generally use the term Service Consumer (capitalized) to refer to the system or application that is making the call. For example, maybe a presentation tier is built with the SEAM Framework on a JBoss 5.1.1 cluster that is running on a RHEL 5.6 VM. I know, a bit specific, but I’m trying to build a concrete image in your mind. Let’s assume that this Presentation Tier makes a bunch of web service calls to back end systems (maybe an ESB, maybe directly to Service Providers) to retrieve data needed to build pages, execute business logic, or begin the launch sequence. We can refer to this JBoss cluster or the application running in it as a Service Consumer. What is it consuming? Probably numerous different web services potentially using a plethora of different technologies mentioned above-why use one technology when you can use three? That question can be the subject of another blog posting.
In even simpler terms, a Service Consumer is anything that calls a web service. In a specific organization’s environment, I would expect to find a set of standards that dictates that Service Consumers are all running on Red Hat JBoss EAP 5.1.1 on Java 1.6.0 using CFX as the implementation for JAX-WS SOAP Web Services. This makes what is meant by a Service Consumer very specific. The most successful organizations I have seen have a handle on the number of different types of technologies being used to implement their Service Consumers (and Service Providers).