Product Wide Web Services
By Acshorten-Oracle on Nov 14, 2008
One of the questions I have received recently requires some clarification as I am getting the same question from partners a lot these days.
The question is this:
"Why doesn't the product have ALL the Web Services it offers predefined?"
Let me explain. The Oracle Utilities Customer Care And Billing product and the ORACLE Enterprise Tax Management product allow almost ALL of its services to be exposed as a Web Service. All online services are exposed and some of the batch services that are drivers for objects (extracts are probably one of the few things you cannot expose as a web service - though you can initiate any batch process from a Web Service).
The product can potentially expose thousands of services (for example Oracle Utilities Customer Care And Billing has over 2000 services).
So why don't we predefine all the services and ship them as Web Services natively?
Apart from the fact there are lots of services (most customers only use at most 20-30 services per implementation) predefining them would reduce their flexibility. One of the key features of the Web Services capability is the ability for a customer to decide which services they want and to customize the composition of those services.
There are two flavors of Web Services in the products. There are traditional Web Services which are Maintenance object based (we have had those since earl versions of the product) which the customer creates a W3C schema describing the attributes and tags to be used to call our service. In other words you decide the API you want to use. To do this you use the Schema Editor in the SDK to generate the service definition and save it. You then register it and it becomes a Web Service.
In recent times we have added Task Optimization to the product. This allows you to "mashup" and reorganize our base Maintenance objects into your own Objects to suite your needs. These objects then can be exposed as Web Services by registering them within the product.
If we chose to predefine them, then we would dictate the API not the customer and that would greatly reduce the flexibility of the product. By giving partners and customers the ability to choose the objects they want to expose as Web Services and allowing customers to decide what those Web Services contain in terms of form and function allows greater flexibility for integration.