Is WCF good option to expose services to Oracle Service Bus

Our company has an Oracle Service Bus Architecture(OSB). My department needs to expose few services to this OSB which will be later consumed by different applications across differe开发者_运维百科nt departments and technologies. I have 7-8 applications and all are Microsoft-based (VB6, C#, SQL Server). My question is whether WCF is a good option to develop our data-based services? Does it integrate well with the OSB? Are there any integration issues? What is the best practice and what transport protocol for wcf should be used in this scenario?

I've been involved in successful projects that have integrated WCF with OSB, using SOAP/HTTP as the transport protocol.

From previous experience, two key risks to avoid:

1. Architectural delineation - you'll need to sort out where the orchestration is going to live, given that both frameworks have support for it, and WCF has all sorts of weird and wacky features that can provide performance benefits.
2. Security integration - while both frameworks provide implementations of common security standards, my experience a couple of years back was that they did NOT play well together.

If the approach is WCF to provide the data integration, and OSB to provide the central point of access and enforcement (along with integration possibly) then fantastic. That's a clear line in the sand.

I would agree with Kevin's response. From what I've seen, the WCF plays quite nicely with Microsoft products but not so well with others. If you keep your WCF service implementation fairly vanilla and leave all the heavy lifting to the OSB (e.g. security, policy, addressing) then you may be OK.

One other trap to be aware of is that WCF appears to bind XML types to native .NET types. While this is OK for most of the types, one thing that caused us lots of headaches was dates. In XML you can have a null date, but in .NET a date is a primitive type rather than an object, and so dies when you try making it null. You can either get around this by processing them as strings (yuk) and converting to/from in your application, or I believe you can also create a custom binding, where you could wrap the date type in a DateWrapper object, to cater for nulls.

Personally I like the model of the service bus being just a facade for an implementation hosted elsewhere, so from that perspective I don't think it matters what technology gets used behind the covers of the OSB-exposed service.

• If you want to use WCF because you like its features and it integrates nicely with your apps, go for it.
• If you're only choosing it because it's all about services and it seems like a good fit for OSB, perhaps see if there are other alternatives that have lower overheads for you and your development team.

In terms of transport, if your data services are about accessing data in a non-transactional way (e.g. retrieve customer details) then SOAP/HTTP is fine. If you are dealing with transactional data, maybe consider a messaging-based transport like JMS or MQ, as from experience the support for WS-ReliableMessaging is not yet everywhere, or consistent.

Hope that helps.