This content has been marked as final. Show 11 replies
I can only help you with some input to question #2.
InterConnect does not offer any help on webservices at all. I guess this is an area where Oracle is quite behind their competitors. If you want to use webservices with InterConnect you will have to do the work youself.
We have been using webservices both for publishing messages to InterConnect and to subscribe messages.
Publish: In order to publish messages we used a standard DB adapter with a PL/SQL procedure which received just the data we wanted to publish. After this we used JDevelopers ability to create a webservice from a PL/SQL package to create a webservice with which you are able to publish a message. The drawback is that you can only create RPC style webservices with Oracles tools (the market is moving towards document style, hope Oracle notices this!). Also I would prefere to be able to have more control over the java webservice implementation to do logging and errorhandling. This way you can only do that in the PL/SQL.
Subscribe: For this we have made a custom bridge implementation that subscribes messages for the hub. Again JDeveloper is used to produce a stub for the webservice that wants to subscribe the data, and when the adapter receives a message from the hub, the webservice implemented by the subscribing system is called.
I am looking forward to see Oracle help us a bit more using webservices and InterConnect. I know they have aquired the BPEL engine, but as far as I can see InterConnect and the BPEL engine does not fit together yet. Correct me if I am wrong.
Feel free to ask for more details on these solutions if needed.
Thanks a lot Peter !! I appreciate your information.
Just to be sure, I assume you implemented this approach to web services on Oracle 9i AS Release 2 .... correct ?
Using JDeveloper web services was my line of thought but wanted to know if anyone had done the same or used any other better approach.
If it is not asking for too much, would it be possible for you to email me as much details as possible on your solutions/documentation at firstname.lastname@example.org
I too am not sure how well BPEL will complement web services for InterConnect.
Actually we are running the webservices on the raw OC4J container (9.0.4) because of other reasons in the production environment.
I have not got the ready to ship documentation (surprise!) but I would like to send you more details. But this will not be until the new year.
Thanks for the clarification Peter.
Any more information that you can send (whenever convenient) will certainly be very helpful and greatly appreciated.
Thank you ...... Merry Christmas and a Happy New Year to you as well !!
1) If you want to use the DB Adapter you should call your PL/SQL procedures directly (a). I think your version b is not good. It sounds that you want to re-implement the features of AQ. If you don't want to call your PL/SQL procedures directly you should use the AQ adapter. By the way, we prefer the AQ adapter instead of DB adapter.
2) InterConnect 9.0.2 does not support web services. InterConnect 10.1.2. comming at the beginning of 2005 will support it. With 10.1.2 you are also able to use the BPEL PM server together with InterConnect.
Thank you Colette.
Why do you prefer AQ Adapter ? - did you find any specific advantages of AQ Adapter over DB Adapter ?
we prefer the AQ Adapter if the integration scenario is asynchronous because of the features of advanced queueing. For example we got a higher transaction security, but not in meaning of a database transaction but in integration transaction. I will try to explain what I mean: If your application server or adapters are down and your PL/SQL-procedure is called you have a problem or you implement a caching by your own (i.e. your idea b) ). But if you are using advanced queueing it is cached automatically by the queue. You only have to enqueue your object in the queue and all other is done by queue or adapter.
This is the most important reason for us but not the only reason we prefer AQ Adapter. Because of using advanced queueing we can uncouple easily our applications from integration logic. And this is a big point for most of our applications. The users should not notice that there are complex integration scenarios behind the application.
Of course, if we have synchronous integration scenarios we do not use AQ Adapter. In that cases we also have to use DB Adapter because advanced queueing will never be synchronous.
Thank you very much Colette !! I appreciate your clarification and help.
sorry but i cannot accept the answer from Colette it is completly confusing and false
The DBadapter is completly asynchronous : the cache is managed either locally on the DBadapter thru file persistence either in the OAIMessage table of the OAI schema on the DB bridge part of the DBadapter
In any case it is resilient to ALL disruptions (network, bridge databases & Hub database) and you will never loose any message.
For information, we are in production since November 2003 with version 9.0.2 with DBadapters
The only differences for me between AQ & DB adapters are :
- No need to install an OAI schema for local persitence with AQ adapter
- AQ adapter more complex to implement because you have to build your XML message to enqueue
- Better integration with IStudio for DB adapter
for your information: in the meantime I go in production with 4 projects using InterConnect. First project go live in May 2003 with 9.0.2 last project in January 2005. Now we upgraded and use 22.214.171.124.
I agree with you that no message is lost by publish or invoke with DB adapter. At this point I express me mistakable. The problem we got was during an synchronous invoke/implement scenario when we got the reply but the calling application was down in the meantime. So who should accept and handle the answer?
But I could not agree with you in other points:
Only if you are using DB adapter you can select "Synchronous" if you are using invoke/implement scenario (when DB adapters invokes the event). Of course publish/Subscribe scenario is always asynchronously.
You do not have to build XML messages for using AQ adapter! You can also use normal pl/sql objects. And this is very easy.
Why do you think DB adapter is better integrated than AQ adapter? I think integration level is the same. There is no difference.
I too feel that both AQ and DB adapters are same at the integration level , depends on the business functionality requirements that differs.