لطفا منتظر باشید ...
Extending the Application
Because the PL/SQL web services run within the Oracle database and share the run-time database resources, there are special considerations when building PL/SQL web services. In this section, we discuss the best practices to implement when using PL/SQL web services.
When to Build Web Services in the Database Server
You have learned the techniques for building web services within the Oracle database. However, since many midtier web service products are available, you should consider whether you really need to build a web service inside the database server, instead of simply leveraging a widely used midtier web service framework. We believe that several issues need to be evaluated to make an informed decision.The first issue is application complexity and code reuse. If you have many PL/SQL programs in the database and you do not want to spend too much development time building a new web service application, you can use the approach discussed in this chapter to publish the PL/SQL packages or procedures as web services.The second issue is data access efficiency. If you want to build new web services that are highly dependent on the data stored in the database and require intensive data computation or large dataset evaluations, running them close to the data within the database server can greatly reduce the overhead needed for cross-tier data communication and synchronization. This sets a clean separation of data-centric logic that runs in the database from business logic that runs in the middle tier. It also lets you leverage the high-performance and highly scalable PL/SQL computing functionality provided by the Oracle database.The third issue is operation efficiency. In this chapter, to illustrate the basic techniques, we built web services that perform simple DML operations. However, in real-world applications, you should not build web services to perform such fine-grained operations, because the benefits of these services do not outweigh the SOAP overhead. Instead, web services should be those services, such as data-mining analysis, that require expensive computational processing in the database.
The fourth issue is the efficiency for processing SOAP message requests. If the web service processes clients that send thousands of SOAP messages every minute, you could overload the database by simply collecting the incoming messages. The Oracle database might have much more important jobs to perform, such as managing and processing the data. In such cases, a better choice would be to build in the middle tier a web service that provides advanced caching and load balancing of the incoming messages.Finally, your decision should not be limited to these considerations. You may also need to evaluate the application design on other issues, such as the security and scalability of your web service application.
Setting Up the Security Protection
Using web services, you can build an open infrastructure that allows easy cooperation and sharing of data and resources within your organization and among your business partners. However, you may also be open to a destructive user attacking your system. In Oracle Database 10g, the database web service is protected both by the servlet security setup within the OC4J server and by the username and password for JDBC connections within the deployed proxy program.In addition to these safeguards, other techniques are available to protect your database web services. For example, you can have security validation of the SOAP messages through either XML Schema validation or other techniques used when processing the XML messages. Alternatively, before the execution of the PL/SQL web service, your application can perform logic-based validations. For example, in the BookSaleService service, you can confirm the partner’s validity by requiring them to provide a password.Because data is critical to business systems, you need to carefully design your application to protect the data when you expose it from database web services.
Building Different Types of Web Services
The approach we have discussed is not the only way for you to publish database computing and data resources as web services, though it might currently be the simplest way to do it. In this section, we discuss other types of web services you can build.
Synchronous vs. Asynchronous Web Services
A web service is just another type of messaging protocol. The service that we created in this chapter is a synchronous service. It works like a remote procedure call (RPC) where, after the SOAP request, the client-side program keeps waiting for the response from the server. However, this is not the only way to design it. In Oracle Database 10g, you can build asynchronous web services by using Oracle Streams Advanced Queuing. This is a useful way for web service providers to use the message queues in the Oracle database to handle a large number of simultaneous requests.
Push vs. Pull Web Services
In the examples of this chapter, the web service is in pull mode, where the service consumers request the service explicitly by sending SOAP messages to the service providers. However, web service communication can be bidirectional, which means that web services can also be implemented in push mode. For example, let’s say the book table on the server side is updated by adding a new column called reviews, which includes the reviews for the books. Then, the bookstore can notify its partners about the changes by sending out SOAP messages using the UTL_HTTP package. Additionally, using XSLT 2.0, you can use <xsl:result-document> to send out SOAP messages by writing into URLs the SOAP messages created by the XSLT transformations.
