Last week at Java One, Ashesh Badani, a Sun SOA marketing person, wanted to have lunch with me to talk about WS-*. He brought along T.N. Subramaniam, Director of Technology for RouteOne, a car-loan aggregator. (Sun loves RouteOne, they’re a reference customer not only for us but for SeeBeyond, which we’re in the process of acquiring). Anyhow, neither Ashesh nor Ashok Mollin, a Sun guy who’s been engaged at RouteOne, got a chance to say much, because T.N. and I hit it off and had a good time talking about Web Services. Which RouteOne are doing, big time and for big bucks and successfully. They are exactly the kind of people that those of us struggling in the WS-* morass ought to be looking to for lessons. This, I think, will be the first ever ongoing piece structured as an interview; with T.N.’s help, I’ve tried to reconstruct our conversation at lunch. I think some conclusions are obvious, but I’ll leave them for you to draw.
Basics ·
I am T.N.Subramaniam. I am the Director of Technology for RouteOne and the
Chief Architect. I have been in IT for over 12 years and as an enterprise
architect for the last 5 years. My main field of expertise is J2EE
architecture and in the last few years XML messaging and now SOA. Prior to
that I was a Math professor for 7 years who did not know how to use a
computer!
Could you give me a 50,000-foot-view of the RouteOne application?
T.N.: Sure. Essentially RouteOne is a Credit Aggregation system. I like to say we are one of the largest early implementors of SOA. Say you go to an auto dealer to buy a car and need financing. The dealer will do a couple of things. First he will run a Credit Bureau on you. Then he is going to get more information from you, rent or own, gross pay and so on. What happens next depends. Just to make it interesting say you have already filled out this information on the Ford Website and they directed you to this dealer based on your zip code. So he has to import all this information. Then he will get some more information from you and he has to then send it to one or more lenders for approval.
As you can see there is a lot of information exchange going on and the Dealers used to do it using a variety of means: FAX, telephone, proprietary web sites of lenders and so on. What RouteOne does is use SOA and web services to get and send all this information as XML messages and thus streamline the auto finance process for the dealer and customer. We are a wholly owned subsidiary of GMAC, Ford Finance, Daimler Chrysler Services and Toyota Finance.
How many downstream (dealer) and upstream (lender) partners, and what’s the message load?
T.N.: I don’t have the latest numbers. But our owners have about 80% of the auto market in the US and Canada. There are roughly 22,000 dealers in the US and we have most of them. Downstream we do most to all the volume for the owners and the independent lending institutions such as Bank of America etc. I can’t tell you the message numbers, but we’re talking high volumes, we’re keeping some big servers busy.
Upstream and Downstream ·
The dealer interface is through the browser?
T.N.: Yes, with a lot of what they now call AJAX, which we started building two years ago.
Do you know what software your upstream partners use?
T.N.: I have some idea about our owners. They are on WebSphere and BEA. But a lot of the lending institutions are also on .NET. But then the beauty of SOA is we neither know nor care. Occasionally an interop question will come up. For instance there was a question of interop in DSig where we switched to exclusive canonicalization. But we follow the standards pretty closely unless we indicate in our specs that we are departing from it for pragmatic reasons. So these occasions have been few and far between.
SOAP ·
Your stuff goes in the SOAP body?
T.N.: There are two parts, maybe three. There is a part which instantiates the vertical schema STAR (Standards and Technology for Automotive Retail) which is actual payload. Then there is the RouteOne block which contains all the meta data. Today we would say it has pieces which would be recognized as belonging to the WS-Addressing, WS-Reliability and BPEL name spaces. I had to make up this since the standards didn’t exist at that time. We should have put it in the header but we wanted to sign the meta data as well so for some reason I decided to put it in the body and seal the whole body.
Of course if we have binary attachments which are PDF documents then it is either SwA or it is a separate part with the attachment base64Binary type.We use both since it’s a measure of difficulty in this area—I mean how do you send binaries in an XML payload—that after 2 months we couldn’t get any agreement among our partners. Nor for that matter have I seen agreement among my peers.
Anything in the SOAP header?
T.N.: Sure, it’s pure WS-Security and it envelopes the Digital signature of the body and attachments. We started out with SOAP-Sec since in late 2002 it wasn’t clear that WS-Security would be widely accepted. But it is and we have switched our partners incrementally.
WS-*? ·
What do you think you need from the WS-* repertoire?
T.N.: As I said, if we were to do it over then definitely parts of WS-Security, WS-Addressing, and WS-Reliability or WSRM whatever comes out of the convergence of WS-Reliability and and WS-ReliableMessaging. Right now I am struggling with this question and I anticipate it will take me a few months.
But standards attempt to accommodate all sorts of scenarios not all of which may be applicable to simpler exchanges. For instance if you are using a synchronous exchange pattern you don’t need replyTo, you have no choice. I think as time goes on I am sure the standards bodies will do what they did in WSDL 2.0 which is making it simpler and cleaner - well somewhat simpler since as you said it still weighs in. I never dared to print out even the core. God bless book marks.
Anyway, my point is in the beginning we imagine all sorts of cases like notification that no one ends up using and we just simplify the specs. At least I hope so or this thing is going to sink under its own weight. Which to me would be great pity since the basic ideas are so simple and I certainly attest from our experience that it is very possible to run large SOA installs even today, just by minding the key concepts captured in the standards sans the bells and whistles.
Hardware Assist ·
Is the
DataPower stuff swappable? I.e. could
you swap in a competitor?
T.N.: Maybe. Every service is facaded in our application so that’s not a problem. But since we didn’t have a standard API for DSig at that time the facade itself may have to change. I know there is a JSR out there for this. I just don’t know what its status is and how may vendors conform to it.
Do you use the DataPower stuff for convenience or for performance?
T.N.: Oh, definitely performance. Actually Sun helped us do the bake-off and a network appliance was definitely the way to go. Right now I have a vendor who uses Bouncy Castle. My performance numbers are way dated now. But I was talking recently to another large European company doing micro-payments and they seem to have come to same conclusion. Of course everyone’s mileage varies.
Messaging ·
How are the upstream conversations done, and are the messages reliable?
T.N.: Actually the upstream part is pretty straight forward. We use SeeBeyond which I see Sun bought which is great news for us since Sun and SeeBeyond are our partners. Essentially we put the message through a sequence of intelligent routers and handlers. So one would respond to the J2EE event to deliver the message, another would get the payload from the data base and another would wrap up payload and meta data in what JBI calls a normalized message and we call a canonical message.
The reliability is quite simple, just what you would expect. We make the message durable and then we retry till the Time to live has expired. In case the instance of SeeBeyond or even any of the eWays fail I still have the message in persistent store. So we run the message through again. Rather to my surprise I have had lender queues go down sometimes for an hour or more and we are yet to lose a message. I guess simple ideas do contribute to robustness. Actually my partner in crime, our SeeBeyond expert Kaushal, can come up with some truly bizarre failure scenarios and we covered a lot of them.
To me the hard part is when we get a response back. It could be text message, a Credit Decision, a fault, what have you. We need to correlate the message with what BPEL would call a correlation set, route it appropriately etc. I can’t wait to get off our proprietary implementation and start using BPEL which does a lot of this out of the box.
Building ·
What can you say about how much work it was to build this
system?
Actually, because of the opportunity costs we had to get it done quickly. I had a draft of the spec for the owners in Aug 2002 once we had a handle on the critical use cases and we got a sign-off in early Sept 2002 after a lot of really thoughtful questions from their architects.
The system itself was designed and built, from documenting the use cases to first testable version, in ten months, and that involved changing at least two vendors! One of the great things about standards based SOA/Web services is the big step is correct design and getting agreement on the specs. Once that is done you can go really fast.
Of course depending on various things the interop testing could go smoothly or you could be in pure hell for a month while you are figuring out what is goofy about some part of an XML message. One thing our readers may be interested in knowing: In J2EE, which is a mature technology, there are the LoadRunners, HTTPUnit, etc. to do the testing. So that often comes as an after thought. Not so in SOA. Because of the lack of maturity and because of the nature of the beast it is best to think of your test harness at design time.
We built a tool called Sim* which Kaushal designed and it simulates complex conversations by responding with canned xml messages which the test team can configure. I really cannot tell you how much of a life saver this was or we would have been flying blind without instruments. My rule of thumb is multiply your SOA costs by 1.5 to accommodate the testing harness and give yourself ample time for interop testing. You don’t want money messages crapping out in the middle of the night.
Relationships ·
How do you set up a relationship with a new upstream partner?
T.N.: We go through huge song and dance on this. Much to my surprise only about 30% of the time is actually spent on the technical side. The problem is there are contracts to be signed, our specs to be shared and reviewed, SLA’s established and since we handle so much customer private information we often have to prove our security and integrity to the lenders such as pen tests, information security, SOX, GLB/FRCA etc.
I mean the legal and security context of SOA is very different from that of Web based applications. For one thing partners are at very different levels of SOA maturity. For another, when transactions cost money and there is no human being at a screen to respond to 404 Not Found in any non-toy SOA application you have extreme security and reliability standards. This is the real issue.
I can conceive of different SOA styles but I suspect the biggest use cases are transferring sensitive information where transactions translate into money. Not whether you wrap the message in a message element or just include it. These things are just trivial issues compared to the real problems you have to solve.
