 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > SOA with J2EE and .NET: Possible, but not easy |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It is not easy to build a service-oriented architecture implementation that supports both J2EE and Microsoft .NET, but based on his experience during a two-and-a-half year project, Rich Colton, application integration manager for Washington Group International Inc, says it can be done.
Three years ago, as he began planning the SOA implementation for the Boise, Idaho-based global engineering and construction company, he investigated the pros and cons of using .NET versus J2EE as the development environment. "I really felt that J2EE was more scaleable and more robust at the time," he said. "I think that's borne out over the last three years. Certainly .NET is coming along, but we chose J2EE." Specifically, he selected Oracle Corp.'s Fusion Middleware, including its BPEL manager, enterprise service bus and Oracle JDeveloper. However, that didn't mean that he was able to ignore Microsoft. "Being an engineering-construction firm we rely very heavily on the Microsoft technology for the desktop," he explained. "Most of our engineering design tools are Microsoft desktop technology. We have to interact." One of the key goals for the SOA project was to provide clean, reliable data transfers between disparate systems for applications such as budgeting and accounting, Colton said. It was important, for example, that codes match between budget and accounting systems so that planners and accountants were dealing with the same data. Where manual transfers had been done in the past it was difficult to ensure that there weren't errors or mismatches in the data. As the SOA project advanced with the server side development being done in Java, but with client side Microsoft applications included in the mix, working with current Web services standards became a challenge, Colton recalls. Components written in Java had to be consumable by both Java clients and .NET clients. That was not as easy as it may look on a white board or Visio diagram because standards adoption and support is still a moving target. "One of the things SOA espouses is interoperability," Colton said. "But the single biggest technology issue that we've had dealing with SOA is that interoperability isn't all that it's cracked up to be yet." In particular he found that W3C standards for data types and WSDL creation were being implemented in different ways in J2EE versus .NET. "Both have gotten better since we started," he said. "But there's still some issues between the two environments that you have to be aware of if you're going to write a Web service for an SOA environment in which you want a client that runs on .NET as well as say a Java client to be able to execute that Web service." As an example, he points to the way the two environments handle the standards for Remote Procedure Calls (RPC). "When you define the type of Web service, you can define an RPC type Web service, an RPC Literal and a document/literal," Colton explained. "Those three are what the open standard defines as the type of payload for a Web service. However, Microsoft only chose to implement RPC and document/literal. They abandoned RPC Literal. On the other hand, the J2EE environments, while they support all three, the early implementations including the wizards that build the WSDL for Web services only supported RPC and RPC Literal." While this may sound like a technical issue, it was really important to an SOA project with a goal of providing accurate data from all sources to various systems and users throughout an international enterprise. "The reason you need a literal type is that basically the payload is non-XML data," Colton explained. "An example is a PDF file. You want to transport a PDF file as a literal type payload." To solve the issue, the development team had to pore over the W3C specifications to figure out how to create a WSDL that both J2EE and .NET clients could use.
"We ended up having to manually build these WSDLs to interact with each other," he said. "That became quite a challenge because there weren't a lot of examples between the Microsoft environment -- what it would accept -- and the J2EE environment. We had to work those issues out." The pain of doing that may have been the downside of being an early adopter of SOA technology. Colton said Oracle's JDeveloper's wizards for building WSDLs have advanced "light years" in the two-and-a-half years since the project began. He also credited Microsoft in improving .NET support for standards. While the interoperability problems remain, the Washington International team managed to come up with ways to get the job done. "We've overcome those issues," Colton said. "It wasn't without some pain in the process, but we feel today that we understand the issues pretty well."
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
