An Oracle SOA Suite - Team Blog

  • News
    August 11, 2009

New adapters for Oracle Service Bus

Guest Author

As promised after the BEA acquisition, we have been working hard over the past year to combine the best assets from the Oracle and BEA product lines, with the goal of making these changes in an additive, non-disruptive fashion. One great example of this was recently released: Oracle Service Bus (formerly AquaLogic Service Bus) users can now leverage the Oracle adapters through a new JCA transport! This opens the door to a whole new range of connectivity options. With the 10.3.1 release of the Oracle Service Bus we are certifying the following adapters for use within Oracle Service Bus (in addition to the existing transports):

  • Oracle AQ
  • Database
  • Oracle Applications
  • SAP
  • J.D. Ewards OneWorld
  • Siebel
  • PeopleSoft

It’s great to be able to deliver on promises – and this is just a start: there’s a lot of other goodies coming from the Oracle-BEA cross-pollination in the upcoming OSB releases. Stay tuned.

(documentation for the above adapters can be found here)

Join the discussion

Comments ( 3 )
  • Roger van de Kimmenade Tuesday, September 8, 2009
    In a SOA platform the OSB should be positioned as a Service provider and the adapters should NOT be part of it it but hided within the implementations of the Services.
    It is great to have the possibilities but is this realy the way the OSB is positioned?
  • Demed Tuesday, September 8, 2009
    Thanks for the comment.
    If you are talking about technology adapters, such as a JMS or database adapter, then indeed, most of the time you want to wrap this in a service. However things get a little more complex when you use an adapter to a more complex and sophisticated environment such as an ERP.
    Several factors to consider here:
    1) any service plugged in OSB is loosely coupled and virtualized no matter whether it is a remote SOAP service or a local adapter. Indeed, a service in OSB is really a combination of a "business service" (the actual service), a "proxy service" (the virtualized service exposed to consumer) and the pipeline in between (that you could use to normalize messages etc.).
    2) Using Oracle adapters architects can decide what is best for their specific environment and use case (many times you do not want to pay the extra cost of going over the wire, through an empty service and lose your transactionality): co-locate adapters in the service bus or use them on the edges (ex: in a BPEL process).
    3) This is a bit of a religious question (also fueled by other vendors that could only speak SOAP in their ESBs): why should technology decide what are the acceptable boundaries of a service? Does a "service" boundary have to have a WSDL interface? A Siebel or SAP administrator might have a different opinion: they expose a service, with a known interface (that they might already have normalized). As long as this service can be plugged in the bus in one way (SOAP) or another (JCA + native protocol) it can be virtualized as well.
    Bottom line: you can have your cake and eat it too! Plug in adapters in the service bus while maintaining loose coupling and virtualization (see #2), or move them to the edges - it's your choice. As a software
    vendor we don't want to dictate one approach or another - we want to leave the final decision to architects such as yourself, as you know best your requirements and constraints (and because we all know that one-size rarely fits all).
    Hope this makes sense and thanks for the opportunity to discuss this further!
  • Pau García Thursday, November 12, 2009
    Hi all,
    I understand that is our responsibility (as architects) to define the way that OSB is used on each customer. The more capabilities it offers the more ways we have to solve the same issue. It's positive, I know, but It has a negative reading too: things can be made in a wrong manner regarding SOA principles, like loose-coupling. Therefore, we must establish the services architecture and best practices, mainly when we engage a quick-win project based on OSB, developing a very first group of services which will help others (customer IT department or 3rd parties) to go on with the SOA adoption.
    Regarding the new JCA adapter, I think that services offered through an OSB adapter should be part of a low level services layer (i.e. connectivity services), which are exposed by higher business services layers. With former ESB (Mediator in 11g) we were used to separate services into two main groups: technology enabling services (Adapters) and business services (Soap Invocation)
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.