by Asim Jalis
1. Why would someone use web services management? Let's imagine
IS manager, Bill. I am the CTO of a hospital. I am trying to
figure out how to streamline the medical billing process. I am
trying to figure out how to use web services to submit medical
bills into the insurance companies and then to receive
notifications when the bills have been reimbursed.
2. It is possible the bills are not reimbursed for the full
amount. I still want to be notified about the action that was
taken.
3. I'll focus on the medical billing industry because I am
familiar with it. The issues in other industries might be
similar. For example, in a financial company integration will
require exposing some web service endpoints and then exposing
other endpoints for receiving notifications.
4. Let's get back to Bill. Either he submits the bills directly
as XML to the insurance company. This is one scenario. Another
more passive scenario is that he exposes his bills as XML, almost
like an RSS feed. He announced the URL to the insurance company
and then waits passively for them to harvest the data.
5. The second scenario might make more sense because this way the
insurance company does not have to worry about their system
getting overloaded with data, in case all the hospitals in the
country decided to upload their data at the same time.
6. The hospital will expose a second web services endpoint to
receive notification when the bills have been processed by the
insurance company. But let's stand back and think about this for
a second. What if the hospital's computer is down? The insurance
company will then have to resend the message to the hospital
periodically until the hospital receives it. Also what if the
hospital's data base goes down. Say it gets infected by a virus.
Does the insurance company really want to be in the business of
reliable message transport?
7. Because of all these cases it might make more sense for the
insurance company to simply expose its endpoint, with all the
data in XML format and then let the hospital harvest it when its
systems are up and when it is ready to receive it.
8. There is a strong case to be made for passive publishing of
data. First, all the integration that web services are going to
enable is about data flow. There is no real computation (or
service) happening at the endpoints. It is all just gobs and gobs
of XML flowing across the web.
9. Exposing web services exposes companies to security threats.
They are in effect allowing outsiders to run services on their
behalf. There might be cases where this makes sense. For example,
maybe the insurance company allows the hospital to verify that a
certain patient is indeed covered by the insurance company. Visa
might have a similar verification service. Verification as a web
service would make sense because an insurance company might not
want to expose all of its patients private information as an RSS
feed. This information is more selective.
10. In general, then, we have identified two different types of
information. The first is passive information that is generated
every day. This information looks most like flow. Example:
medical bills, which are generated daily. They are associated
with events.
11. A second type of information is time-independent. For
example, customer account information. While this information
evolves over time, the customer record does not get generated
every day. There is a single customer record which represents a
kind of a current snapshot of where the customer is.
12. For example, a customer's record might have his
mailing-address. This will change over time -- it will change
every time the customer moves houses -- but at any given time
there won't be multiple customer records representing his
different addresses over time. Instead there will be a single
customer record.
13. Here is another way to understand this difference. The
medical bills are logging data. The customer address is state
data.
14. Now for the bold claim: web services only make sense for the
stateful data. They don't make sense for logging data. Logging
data, which is related to time, is much better served passively.
15. But now let's argue for the contrary view. Even logging data,
for example RSS feeds, could be served as a web service. While it
is true that it makes sense to serve it as a static XML file, it
is also possible to hook up a web service that returns a giant
array of records every time it is called.
16. I am trying to get at something subtle here. Perhaps the
distinction between web services and RSS feeds is artificial. The
main point is that there are two kinds of data. There is stateful
data. And there is logging data. Logging data is tied to time and
events. Stateful data can change over time, but it is not keyed
based on time. It is keyed based on something that is likely to
be invariant over time -- for example social security numbers.
17. So the distinction is: data with time-based keys versus data
with time-independent keys. The second group could also be called
data with time-invariant keys.
18. Gartner reports that while around 80% of the firms in their
survey are using some form of XML, only about 1/4 of this group
is using SOAP or web services. The vast majority is using XML to
transfer data, without tying it up with SOAP and WSDL.
19. Here is the argument against the contrary view in 15. When I
say web services I really mean messaging based on SOAP/WSDL. RSS
is an example of a non-SOAP-based XML data format.
20. Gartner's survey might indicate that more companies are using
RSS like data feeds than are using real web services.
21. Getting back to our hospital example, the an RSS-like feed of
the data is extremely fast and it will consume far fewer
resources than any other scheme. It could be placed in logging
directories based on date. So, http://.../2003-10-14/data.xml
could be the data for a particular date. As long as both parties
understand the convention of the URL and understand what the
underlying XML means the data transfer should be successful.
22. An important issue here might be privacy. The hospital will
want to control who can access the data.
23. A simple way the hospital could implement privacy could be
through HTTP security. It could require HTTP login and password
information, which it stores in a htaccess file. Why hasn't
anyone leveraged HTTP security more in the web services arena? In
my mind the purpose of building web services on HTTP was to allow
the HTTP infrastructure to be leveraged. And yet this completely
legitimate security infrastructure is largely ignored by web
service mavens.
24. HTTP security would work both with RSS style feeds and also
with web services.
25. The htaccess passwords would ensure that only the insurance
company, or a select set of insurance companies can access the
directory containing the medical bills for the day. Or the
hospital might publish different directories for different
insurance companies.
26. On the other side, the insurance company could publish its
own billing updates -- such as approval notices -- on
date-indexed websites. It might also index the directories by the
names of the hospitals. Again, htaccess-based password scheme
should keep the records safe.
27. What are the management requirements besides security? I
suppose Bill wants to know who has uploaded his RSS feed and
when. However, that too could be published as an RSS-style feed.
This feed might be restricted just to Bill and his staff.
28. Bill might also be interested in the performance of his
network. He might be interested in how long each query took to
service. This could be filed away again in an XML log file. The
log file could contain attributes such as:
- how long it took
- who made the call
- what time the call occurred
- how big was the response in bytes
29. To summarize we have defined an RSS-like architecture for
integrating medical billing using XML between hospitals and
insurance companies. We might still need schemes to figure out
what the password protocols will be to ensure security. To
understand that we will have to play with some password
scenarios.
