|
Articles Index
In 2002, General Motors Acceptance Corporation (GMAC), Ford Motor Credit Company (FMCC), Daimler Chrysler Services (DCS), and Toyota Financial Services (TFS) created RouteOne LLC to provide a credit aggregation management system (CAMS) to serve some 80 percent of the 22,000 auto dealerships in the United States. Prior to RouteOne's formation, auto finance was encumbered with time- and energy-consuming procedures that functioned through disparate business systems requiring data entry into multiple separate applications, which led to errors. When a customer met with an auto dealer to buy a car and establish financing, the dealer ran a credit check, then gathered information about income, homeowner status, and so on, and typically sent it to lenders for approval by fax, telephone, or the lenders' proprietary web sites.
 Did You Know?
You can use Sun Java Studio Enterprise to build an effective web service. Sun Java Studio Enterprise frees you to focus on business logic because it handles the low-level details of web services, such as SOAP and WSDL, with time-saving wizards and test clients. | | |
 |
RouteOne was charged with creating a faster, easier, more accessible, and less error-prone system that reduced or eliminated reliance on paperwork, faxing, and phone calls. The company consulted with Sun Microsystems' Sun Services and created a service-oriented architecture (SOA) that linked all parties in a single, seamless chain that enabled them to share relevant information in real time.
The end result is a web-based CAMS that uses an infrastructure consisting of Sun Fire servers, Sun Java System, and Java Web Services and SeeBeyond technology. Accessible from RouteOne's corporate web site, the CAMS solution integrates credit application, loan verification, and credit-reporting systems, providing seamless access to a single interface for vehicle financing. Rather than spending time reentering the same data into multiple credit-application systems, dealers are free to spend more time selling cars and caring for customers, who now spend less time in the finance office.
Java Platform, Enterprise Edition (Java EE, formerly J2EE) technology provides the application programming interfaces (APIs) needed to create and deploy interoperable Java Web Services. RouteOne uses SeeBeyond for its integration server and leverages Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and Java Message Service (JMS) as its common information-sharing technologies. These Java EE technologies also helped RouteOne's CAMS solution meet the open-standards goals of the Standards for Technology in Automotive Retail (STAR) group, an industry-funded initiative promoting common Internet-based data exchange networks.
The successful establishment of RouteOne's pioneering architecture makes it apparent that SOA is here to stay.
Recently, RouteOne's T. N. Subramaniam, along with Sun's Ashok Mollin and Ashesh Badani, presented a session on Pragmatic SOA at the 2005 JavaOne conference. They concluded the presentation with advice for aspiring SOA architects and adopters:
- Start simple, don't let the alphabet "SO[A]up" overwhelm you.
- Let business identify the service.
- Think XML documents, not objects.
- Use SOAP as an envelope but not for binding.
- Use Web Services Definition Language (WSDL) 2.0 for description, not code generation.
- Think asynchronous conversations.
- Use Web Services Business Process Execution Language (WS-BPEL) to orchestrate the process.
- Use Java Business Integration (JBI) for integration.
- Keep learning. This is not finished.
We caught up with Subramaniam and Mollin recently to explore these and other topics related to SOA. Subramaniam, RouteOne's director of technology and chief architect, has been active in IT for more than 12 years and an enterprise architect for five. Ashok Mollin is an enterprise architect at Sun Microsystems with 15 years of industry experience. The last five years, he has worked closely with enterprises, helping them adopt Java EE technologies.
 Let me start by asking you this: What do you think is the most important rule to follow regarding SOA implementation?
T. N. Subramaniam: I would suggest two basic rules: Make it loosely coupled and make it coarse grained. Remember that you are integrating with external parties. And when you have multiple business partners, as we do, you just can't afford to be tightly coupled, or every time one of the 80 companies you work with upgrades or changes -- well, you do the math. Also, remember we are integrating business processes across the wire. These integration points are usually defined by vertical industry standards. So you integrate with STAR or TOLEC (Transfer of Location of Electronic Chattel), not with fine-grained APIs. The key point is to think integration, not APIs.
Ashok Mollin: I agree that those rules are very important, but the most important thing in my opinion is that we need a top-down approach in which business drives the process and dictates what services are required, rather than IT wanting to spend a year making everything into a service. Also, not all systems and everything in the enterprise has to be an exclusive service.
What has surprised you the most about SOA?
Subramaniam: What surprised me the most is the amount of variation in the levels of sophistication of the people with whom I've worked. For technical people like me, there is the temptation to think, "But isn't everybody out there implementing WS-something" -- whether BPEL, JBI, or whatever? No. For instance, there is this idea that you're not doing SOA if you're not on the leading edge and doing all of it. Developers should be cautioned that not everyone has the same level of sophistication.
If you're going to do SOA, you should be willing to work with RESTful partners. You should be willing to do SOA where it's just an XML post. Levels of sophistication are all over the map. Some people will like digital signatures. Some people will complain about it. Some people will look at your specs and get it. Some people look at your specs and repeatedly ask the same question. This is not like a J2EE application, where you control everything. With SOA, you're completely dependent on business partners.
Another surprise is that the milieu is very different, in that machines are talking to machines and exchanging messages. And most of the time, SOA is in a business environment: You're doing it because you expect to make some money or you have a value-added proposition to offer to somebody. That is a different political context. There are legal and financial implications from which developers have been shielded for a long time. You can no longer consider yourself shielded. The business context becomes very important.
Mollin: I have been surprised, from both the customer and industry perspective, at how much SOA involves far more than IT folks. It involves management and business people at many levels, from top to bottom. Even web services did not go all the way to the top -- it was mainly IT and technical people. From an industry perspective, even open-source and freeware companies like Apache and JBoss have come together with commercial companies -- Sun, SAP, Oracle, etc. -- to create the Java Business Integration (JBI, JSR 208) spec in a very short time. This is big, given the importance of SOA.
Subramaniam: I agree completely. Back in 2002, when we started, we had to involve four companies that have traditionally been competitors. They showed enormous willingness to contribute and asked some very good questions. There is something about SOA that brings people together. It wouldn't work any other way.
Standards Gaps in SOA
What are the biggest standards gaps in SOA?
Subramaniam: Developers should not wait until standards get sorted out before adopting SOA. WSDL, which describes the interface, already exists, as does a form of WS reliable messaging. There are competing standards that will eventually be reconciled. People are not talking much about WS-Transaction, but it is important. WS-Security is well accepted. SAML (Security Assertion Markup Language) and XML DSig for digital signatures are both accepted, as are XML schemas. It isn't so much that individual pieces are missing -- the pieces that I thought were missing are being addressed by JBI and BPEL (Business Process Execution Language). There are, to be sure, gaps between the specs. For instance, should you use WS-Addressing or the message payload for correlation of messages? But these are low-level questions.
|
|
"Developers should not wait until standards get sorted out before adopting SOA."
T. N. Subramaniam
Director of Technology and Chief Architect
RouteOne LLC |
|
The real issue today is: How does it all fit together? Show me a picture that says, "Here is where the reliability sits." Is it a JBI service provider? Do I bake it in? Is it in the binding component? What is the solid, standard architecture that fits all of these pieces together? This is still up in the air. A lot of people like me are drawing a lot of pictures on our whiteboards and asking, "What is a good architecture that puts all of this together?" SOA requires people to adopt a new paradigm in which applications are a collection of both external and internal services. As Sun's Tim Bray puts it, this is not CORBA with pointy brackets.
Mollin: Let me comment on the gaps. I would like to know: What is the canonicalized XML going to look like? In the auto industry, we have standards like STAR, and in the case of the mortgage industry, we have MISMO (Mortgage Industry Standards Maintenance Organization), which are, in essence, canonical XML. But if a company -- or companies of similar business domain -- want to adopt SOA, they need a standard message document. There's no definition for the standard yet. So someone has to take the initiative of bringing in such standards for exchanging information.
Subramaniam: We all have to sit down and hammer out these specs, and we won't get them right the first time. That's the cost of doing business in this area. I'm sure one day there will be a book, Design Patterns for SOA, but we're not there yet. Allow me to give some advice for people who are struggling with SOA.
The important thing is to understand the challenges of what I call SLOB -- stateful, long-running, orchestrated business conversations. You have to handle reliability. You have to be able to perform stateful transactions. You have to be able to coordinate message exchanges, where there are basic problems. Try to understand these concepts. How you actually solve them doesn't matter so much. It's more important to be aware of what problems you have to resolve.
Mollin: I agree, spec is more for exchanging information. However, things like reliability, security, availability, etc., are more important and critical if one has to design and implement solutions to handle them. Products in this space are slowly maturing.
Doing It Differently
What would you have done differently at RouteOne?
Subramaniam: I think we got a lot of it right. But our tags for Reliability, Addressing don't have the standard names of the WS-* specs. And there are some things the standard provides that we don't. But despite that, it has had a lot of value for us. After all, we have had a successful business for nearly three years.
I didn't anticipate JBI, which was approved on June 20, 2005. The documents went public in March 2005. This is probably one of the most important specs to come out of Sun in this space. It will do for the integration space what J2EE did for the transaction space. I wish I had coupled things a little more loosely. I wish I had partitioned the SOA aspect layers better. One reason I'm so attracted to BPEL and JBI is because they help me do what I personally didn't get right!
The Next Big Thing
What should IT professionals generally be aware of about the potential of SOA and web services?
Subramaniam: The one-sentence answer is: It's going to change your job and increase opportunities. SOA is the train of the future. I think of people in IT as surfers looking for the next big wave. Whoever knows enough catches it first and rides the wave. But sooner or later, like it or not, it (the innovation) gets commoditized, and the best practices come after it is in wider use.
"I believe that, after the web, SOA is the next big thing. It's good for another 5 to 10 years. Just as the web changed the world, so will SOA."
T. N. Subramaniam
Director of Technology and Chief Architect
RouteOne LLC |
|
I remember a time in the dot-com boom when I couldn't hire anyone who knew servlets for less than $70,000. Today, who's going to pay $70,000 for someone who knows servlets? But SOA work is not just programming to some API. Standards like BPEL are very declarative, and there is a premium in understanding the integration process and how to leverage the standards. One thing that surprised me about JBI, for instance, is how much of it is directed to the service provider.
I believe that, after the web, SOA is the next big thing. It's good for another 5 to 10 years. Just as the web changed the world, so will SOA. But the difference is that SOA is business process- and integration-oriented, and there is a huge potential there.
Mollin: I would say: Don't get overwhelmed, be calm, and move slowly. To repeat myself, you don't need to make everything a service. Work closely with the business people to find out what is appropriate to be made a service. Focus more on integration aspects. Exposing services across systems across enterprises is the next big thing.
Subramaniam: To reinforce what Ashok said, there is a real danger in IT in what I call résumé-itis, in which someone says, "Here's the latest and greatest. I've got to do this. Somehow I'll persuade somebody in the company to spend a lot of money to implement it." I don't think IT is about the latest and greatest. It's about solving real-world problems. Don't follow a technology blindly, because half the time, it's not appropriate for what you're trying to do.
A Warning About SOA Products
So would you be cautious if someone tried to sell you an SOA product?
Subramaniam: If someone said to me today, "I have a great SOA product for you," I would be very careful. We are in the early days of SOA, where we are just beginning to define the problems we need to solve. So if someone is telling me that they've already solved them for me, I would be very skeptical. I am not even sure what that would mean. We will need time and experience to distinguish between good and bad SOA products.
Mollin: SOA can't be solved by a single product. SOA requires an ecosystem in which people can adopt the new architecture and utilize a mixture of products and services -- Product A's services talk to Product B's business. SOA calls for a mix and match of architecture and products. SOA does not retire legacy and does not recommend a change in existing applications or products. SOA is about enabling existing applications as services.
What should developers interested in SOA focus on?
Subramaniam: I have a tendency to say: "Let me download something and write some code," but that misses the point. SOA is not about code -- it's a way of thinking about a problem. You should start thinking more abstractly. How are you going to put everything together? Which of the specs contribute value to your solution? Learn the specs, define the problems you have to solve, and devise creative solutions to pull it together. The code will come. SOA developers need to think more from an architectural standpoint.
A good example is BPEL itself, where you're not writing a lot of code. You're writing XML descriptions of how the process should flow. That is not about writing code. It's more about understanding process patterns.
Misconceptions About SOA
What are the major misconceptions about SOA?
Mollin: People confuse SOA and web services, which are not the same thing. SOA is not a web service. A web service is not SOA. Web service is one direction you might take with an SOA. And SOA is not a product. SOA is an architecture style.
Subramaniam: At one time, people tended to think that SOA was just vaporware, just hype. That is not true. SOA is real, and the technologies for it exist. It's not just some buzzword.
Building on SOA Functionality
How does RouteOne plan to build on its SOA functionality?
Subramaniam: Fortunately, we've implemented a lot of it, and the concepts are in place. We have struggled firsthand with the problems that SOA tries to solve. Our biggest challenge may be convincing people of the importance of implementing SOA in a standards-compliant way. What we created works, so people want to know what they get by adhering to standards. If we don't use the standard, then we will not solve the next problem that arises nearly so well. So it's important to start slowly migrating away from proprietary implementations.
Effects on Customers
What has this meant for RouteOne as a business and for RouteOne's customers?
Subramaniam: RouteOne exists -- SOA or no SOA -- to make the experience of buying a car more pleasant, and it has succeeded at that. It's also enhanced the dealer's life because it increases the turnaround time in which they get responses and the speed of their business flow. So, on an average day, for example, a large dealership might sell 200 cars. Imagine 200 stacks of paper, which have to be faxed and entered into multiple sources.
|
|
"People are genuinely shocked to hear that we wrote the whole spec in 90 days. Our whole messaging was implemented in three-and-one-half to four months."
T. N. Subramaniam
Director of Technology and Chief Architect
RouteOne LLC |
|
RouteOne did our version of SOA back in 2002, when it was just a buzzword, because there was no other way to do it. I was a J2EE and messaging architect doing J2EE and EJBs like everybody else, who had thought a lot about leveraging XML and JMS-based messaging. I saw that it made sense to exchange XML documents to do business in a highly heterogeneous environment in which I knew nothing about our partners' implementations.
People are genuinely shocked to hear that we wrote the whole spec in 90 days. Our whole messaging was implemented in three-and-one-half to four months. It's very fast. You can get a huge ROI. If your business customers agree with you on standards, you can go really fast.
What have been the biggest challenges you faced with your project?
Subramaniam: We literally had to invent everything from the ground up. How do you handle security, reliability, transactions for long-running conversations? How do you exchange binaries? What defines a business conversation, anyway? How do you satisfy the myriad state and federal legal requirements?
For the last two-and-one-half years, we had to come up with creative solutions for one problem after another. Those engaging in SOA today are much more fortunate. Standards now exist to help solve these problems. But I feel very fortunate in seeing the problems to be solved up close and personal. At least I have an acute appreciation of the standards and what works and what doesn't in the real world.
Author's note: Many thanks go to Ashesh Badani, Sun's group marketing manager for SOA, for his contributions to this article.
See Also
|