Where to Start
Web Services can be used to crush the barriers to business integration. Business integration is a good idea at any time, but your recovery will accelerate if you use Web Services to work more closely with your suppliers and customers. Think of Web Services as XML links to customers,
, and operating groups. Without them, you ll write one-to-one interfaces. You would write the interface for one vendor. Let s just say it takes you ten weeks to write the interface that would link your procurement system to your supplier s inventory system. Each additional vendor interface would take ten weeks, as well. Prior to Web Services, you had to have the same integration vendor on each side, too. A lot of resources (time, money, etc.) would need to be invested upfront on a proprietary technology and virtual area network (VAN) connection. Because Web Services use an
standard, you can use any vendor, can add a thin layer of technology over your existing systems, and, in many cases, send data encrypted over the public Internet. Instead of taking ten weeks to integrate the first vendor, it will take two to three weeks with Web Services. For
in the old world, it took another ten weeks. With Web Services, it will take you about one week. That s ten times faster!
You can use Web Services to link to your suppliers, connect to customers, or simplify your internal interfaces ”all using a fraction of the resources needed to develop, test, and implement using traditional (i.e., non-Web Services development)
fruit for Web Services is where the pain is greatest: linking to customers and suppliers. Maybe you want to open your production schedules to partners and suppliers or tie your order management system to your customer s purchasing software. There is also a great opportunity to simplify your internal systems. You could retool your pricing engine with Web Services interfaces to offer it as an internal service. Web Services also are the right technology for simplifying internal systems. Instead of building the same
functionality over and over again in each business unit or for each customer channel, build it once and reuse it everywhere. As an example, a very large bank has seven mortgage rate
”one for each channel and each kind of customer. That causes all kinds of problems: the rates can be different over the phone than from the web site, and the
are seven times the effort to build and maintain. What s the solution? One mortgage rate calculator with Web Services interfaces that is used in every channel and application. What does this mean? The Web Services solution provides a more consistent customer experience, more control over a business driver, and lower total cost of ownership.
Now that you know where to get started, the next question is how to get started. First, you must bring IT, business, and marketing together.
, you ll need to prioritize the services you should build to the business.
of Web Services
All new technologies are inundated with buzzwords and acronyms that attempt to describe them, but these often produce the
effect of making the new technology harder to understand. The Web Services world has its share, as well. To explain the buzzwords, think of a Web Service as a package that will be shipped to a customer.
XML, or eXtensible Markup Language, is used to build Web Service messages that go from one server to another. As you ll see in this chapter, by using JDeveloper, the developer will not need to know much about it to create a Web Service. When it comes to shipping our package to the customer, XML is the alphabet.
SOAP, or Simple Object Access Protocol, is what enables the exchange of information over a network. SOAP is an XML-based (text) protocol specification. In other words, SOAP messages are built with XML. The messages are, therefore, platform, protocol, and language independent. The standard doesn t specify a transport mechanism. As a result, messages can travel on HyperText Transfer Protocol/Secure HyperText Transfer Protocol (HTTP/HTTPS); i.e., web site POSTs, Simple Mail Transfer Protocol, or SMTP; i.e., via e-mail, or File Transfer Protocol (FTP); i.e., file transfer. SOAP provides a standard so developers don t have to invent a custom XML message for every service they want to make available. The SOAP message specifies the service
, the method
implemented by the service, the method signature of each method, and address of the service implementation (
as a Uniform Resource Identifier, or URI). Oracle supports the HTTP and HTTPS transports only. The good news about HTTP and HTTPS is that this information is provided through firewall-friendly ports ”messages are transported using existing communications protocols and
. When it comes to the package that we re sending to our customer, SOAP addresses the envelope or package.
WSDL, or Web Services Description Language, is actually a file containing XML that describes the Web Service interfaces and locations; it describes the methods or programs that you can call in the Web Service and input/output parameters for each method. When it comes to the package that we re sending to our customer, WSDL describes the message. Think of WSDL as the metadata about the Web Service. This is the mechanism that provides the
qualities of a Web Service.
UDDI, or Universal Description, Discovery, and Integration, specifies a standard business registry by which people can publish/discover information about Web Services. It also specifies a directory naming service (DNS) for business applications. UDDI registry
contact information for a given business
information that categorizes businesses (industry, product, etc.)
technical descriptions of provided Web Services
There are currently a number of UDDI providers, including Oracle (http://otn.oracle.com/tech/webservices/htdocs/uddi/otnuddi.html), Microsoft (http://uddi.microsoft.com), IBM (http://www-3.ibm.com/software/solutions/
/uddi/), and SAP (http://udditest.sap.com). When it comes to the package we re sending to our customer, UDDI is the directory of services that we can use.