FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Architecture Blog: .NET/Java Interop: A Reason for Web Services
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
May 29, 2007

.NET/Java Interop: A Reason for Web Services

Udi Dahan writes that ".NET/Java Interop is not a reason for SOA".

Udi says that companies that need to integrate two technologies turn to Web services and that:

The only problem is that in order for things to work right, they really must have a chatty interface, and flow transaction context between these “services”, and all the other things I describe as anti-patterns.

Udi is right in that if you don't rethink and remodel your systems, you will (probably) not have an SOA as you are likely to find your self implementing anti-patterns like those he mentions.

However, using Web services does not automatically mean that you are doing an SOA. If you don't think about moving to SOA, you can still opt to use Web services as a remoting or RPC technology to connect two systems. The advantage over the other proprietary products Udi mentions is that Web services are a standard technology. This will work well or fail if orthogonal to the technology choice. It depends on the architectures of the systems you integrate. If you need to flow transaction between the systems you'd also need that even if you cross-compile one of the applications in the other environment.

Another thing I don't agree with is the word must Udi uses. First, while it is likely that older systems have chatty interfaces, it is not mandatory. The designers of the legacy system may have thought about the consequences of distribution without regard to SOA. Also you can still wrap an existing system with a service contract (using Web services or any other technology) and not get to chatty interfaces, etc. However that means that the wrapper should have some substance or business logic inside it to mask the old system's behavior this is especially important if you are thinking about moving to SOA and you take into consideration that the business will not just halt and wait there until you are done. You have to think about interim solutions, such interim solutions can include wrapping a legacy system with an Edge Component and a SOA facade (a pattern I call "Legacy Bridge") while you move in the grader direction of a full-blown SOA.


Posted by Arnon Rotem-Gal-Oz at 04:42 AM  Permalink




 
INFO-LINK