SOA / Web Services as Service Personnel
Explaining SOA / Web Services to non-technical people is not always easy.
Web services can -- depending on your business and the granularity in which you implement your web services -- be modelled as the service people who previously -- in an earlier non-web age -- performed those services.
This entry is an attempt to make web services more understandable to non-technical people.
Let's start. Let's use a library which has a document delivery service (for which is charges), which in the present web age delivers documents in both analog (paper photocopies) and digital form. We'll start with how one might have done this in the past (I admit this example presents things in their extreme: in the real world one service person performed a number of service roles. But please bear with the example).
You are a researcher. You are looking for the following article, i.e. you want a copy of the following article:
When people were involved:
Example 1: Do it youself:
You contact the "Find article" (FA) person by telephone at the library. You give them the article information. They call you back and indicate that they do have the article. They give you a unique identifier for the article that you write down, and give you the telephone number for the "Deliver article" (DA) person.
With this unique identifier for the article that you want, you then telephone the DA person. The DA person takes the article identifier and asks you for what institution you work. You reply "The Foobar Institute". The DA person indicates that -- for clients from your institution -- that this particular article is not available free-of-charge -- and indicates that they cannot give you the article until you make arrangements with the "Pay for article" (PFA) person. You telephone the PFA person, who takes the identifier of the article and tells you that it will cost you $10 for the article, how would you like to pay? You give them your credit card number, and they say that they will call you back. They call the credit card company authorization (CCCA) person (external to their organization), and give them all the information about you, the purchased article and the price. They get an authorization number from the CCCA person. They call you back and indicate your transaction was successful, and give you the transaction number.
You then call back the "Deliver article" (DA) person, and give them:
Explaining SOA / Web Services to non-technical people is not always easy.
Web services can -- depending on your business and the granularity in which you implement your web services -- be modelled as the service people who previously -- in an earlier non-web age -- performed those services.
This entry is an attempt to make web services more understandable to non-technical people.
Let's start. Let's use a library which has a document delivery service (for which is charges), which in the present web age delivers documents in both analog (paper photocopies) and digital form. We'll start with how one might have done this in the past (I admit this example presents things in their extreme: in the real world one service person performed a number of service roles. But please bear with the example).
You are a researcher. You are looking for the following article, i.e. you want a copy of the following article:
Kendrick, B. 1962. The Leptographium complex. Verticicladiella Hughes. Can. J. Bot. 40: 771-797.
When people were involved:
Example 1: Do it youself:
You contact the "Find article" (FA) person by telephone at the library. You give them the article information. They call you back and indicate that they do have the article. They give you a unique identifier for the article that you write down, and give you the telephone number for the "Deliver article" (DA) person.
With this unique identifier for the article that you want, you then telephone the DA person. The DA person takes the article identifier and asks you for what institution you work. You reply "The Foobar Institute". The DA person indicates that -- for clients from your institution -- that this particular article is not available free-of-charge -- and indicates that they cannot give you the article until you make arrangements with the "Pay for article" (PFA) person. You telephone the PFA person, who takes the identifier of the article and tells you that it will cost you $10 for the article, how would you like to pay? You give them your credit card number, and they say that they will call you back. They call the credit card company authorization (CCCA) person (external to their organization), and give them all the information about you, the purchased article and the price. They get an authorization number from the CCCA person. They call you back and indicate your transaction was successful, and give you the transaction number.
You then call back the "Deliver article" (DA) person, and give them:
- the document identifier
- the credit card transaction number
They call you back and indicate that they do have the article and that their records now indicated that you have paid for the article but have not been delivered the article, and take your delivery information in order to get you the article. You get a photocopy of the article in the mail.
Example 2: Have someone else do the work for you:
Instead of doing all of the work described above in Example 1, you contact an intermediary service (IS) person, with whom perhaps you already have a relationship (i.e. they have your institutional affiliation information , you payment information, your delivery information, etc). The role of the IS is to take your information and to do all of the interactions that you might have done with the various primary service persons.
They are your proxy or perhaps act as a broker.
Think of asking your research assistant to track down and get a copy of this article, or -- in a different example -- a travel agent acting for you, doing all of the interactions you might have done, such as booking flights with the airline booking service person (pre-Sabre), reserving rooms with hotel reservation service person, and renting a vehicle with the vehicle rental service person.
The IS could survive on any one of a number of business models:
Example 2: Have someone else do the work for you:
Instead of doing all of the work described above in Example 1, you contact an intermediary service (IS) person, with whom perhaps you already have a relationship (i.e. they have your institutional affiliation information , you payment information, your delivery information, etc). The role of the IS is to take your information and to do all of the interactions that you might have done with the various primary service persons.
They are your proxy or perhaps act as a broker.
Think of asking your research assistant to track down and get a copy of this article, or -- in a different example -- a travel agent acting for you, doing all of the interactions you might have done, such as booking flights with the airline booking service person (pre-Sabre), reserving rooms with hotel reservation service person, and renting a vehicle with the vehicle rental service person.
The IS could survive on any one of a number of business models:
- They might charge you direcly for this service.
- They may have a brief paid advertisement that you hear when you first telephone them.
- They may receive a fee from the companies whose services they have brokered for you (in which case you would have to be careful as they may choose the services for which pays them the highest fees, as opposed to delivering to you the best rates/quality).
To the Web: When people are not involved (except for the client)
Now, let's move this to the Web and SOA / Web services world.
Instead of a telephone, you are using some kind of web browser, on whatever device.
Instead of service people, your web browser is interacting with a series of web applications which invoke web services. These applications reside at the library, on their web servers.
The first application takes your article information and, using the "Find article" web service, tries to determine if the library has or can get, this article. They can. A web page is presented to you indicating this, and a link to the "Deliver article" web page is also presented to you. Embedded in this link is the article identifier.
You click on the "Deliver article" link, which presents you with a web page form from which you select the institution to which you belong (or it uses you IP to discover this, or you type in a userid/password, etc.). When you submit this page, the "Deliver article" web service is invoked and the application returns a page that tells you that you do not have free access to this article, and that you must pay for it, and presents a link to the "Pay for article" page. Embedded in this link is the article identifier and a key to your ID information.
The "Pay for Article" page has a form in which you type in your credit card information. When submitted, this invokes the "Pay for article" web service which:
- Uses another web service to authorize the credit card transaction
- Records the transaction in a database (or perhaps uses another web service to do this).
A page is now presented indicating that the transaction was successful, and a link is made back to "Deliver article". Embedded in this link is the ID of the transaction. The "Deliver article" application again calls the deliver article web service which, using the transaction ID, gets the article information, etc and sees that the article has been paid for and delivers it to the
user's browser.
------
These two modes -- pre-web using people and post-web using web services, are not that different. It is the same business model. Instead of using service people and the telephone (and regular mail) to deliver the article, a web browser and web services (and the Internet) are used.
-----------
Notes
- This is a simplified implementation and does some things in a naive fashion, security-wise, to simplify explanation. Things like the credit card transaction number would never be passed around in a web environment in the fashion describe above.
- Web services do not always map to services which were previously performed by service personnel. But there are many examples where these are the case and may be the appropriate way to model and implement your system. Use cases often (but not always) are mapped to specific real-world distinct services, which are often part of the services provided by a service person.
Comments