|
Looking for Balance
Proponents of .NET and J2EE architectures are determined to seize the high ground in an evolving Web services-oriented technological landscape. But despite the rhetoric, neither .NET nor J2EE is inherently superior for creating the business functionality that Web services ultimately expose. Each has features that make it better for a specific enterprise, division, department, or team in a given situation. Your organization is better off learning how to bring the technologies together rather than trying to pick "the" solution that it should always use.
 |
|
| Jake Freivald |
This shouldn't surprise anyone. We've always worked in heterogeneous environments, despite the fact it's difficult to do so. The addition of Web services, which promises easy integration and integrated supply chains, will make us more likely to accept heterogeneity, not less.
Of course, questions linger about whether Web services are enterprise ready. Numerous demonstration projects exist, and many more are in the works, but we're still waiting for evidence Web services can handle transaction-intensive, multi-functional demands across organizations and even supply chains. Although Web services are ideal for data exchange and enabling remote queries, they're less effective at supporting applications that require uninterrupted sessions without data loss. Additionally, development for XML schema and other critical standards are still in process.
Adding to the concern, the purity of the Web services vision has been muddied by vendor self-interest. Web services are often defined in terms of J2EE and .NET, which means committed vendors are striving to make Web services into another wrapper that third parties use to interoperate with their core technologies. This increases the risk that vendor support for Web services standards will diverge, just as we saw when ODBC first gained ground about 10 years ago.
That said, Web services promise to be useful in due time. Meanwhile, enterprises should expect to use both .NET and J2EE where appropriate, regardless of their Web services investments. Corporations have always been unwilling to throw out something that works in favor of something unproven. You should expect to see the coexistence of legacy technologies, .NET, and J2EE, with Web services being added slowly as demands mount and standards solidify—especially in light of recent large e-business investments. This might not be what you've hoped for, but the picture isn't completely grim for several reasons.
Both J2EE and .NET have strong built-in integration capabilities. J2EE offers J2EE Connector Architecture (JCA), which enables integration with Siebel, Oracle, SAP, and other enterprise applications, without leaving the Java programming environment. Supported by almost all major vendors, JCA specifies how to build adapters that understand how to communicate with existing systems. For its part, Microsoft defined many standards used for integration today, such as ODBC and OLE DB, and continues to supply tools such as BizTalk Server, Host Integration Server, and Data Transformation Services to enable different sorts of integration. Companies can also obtain adapters that facilitate integration from multiple third-party vendors. Such adapters simplify integration by dramatically reducing, or even eliminating, the need for custom integration code.
Ultimately, the enterprise of the future will be characterized by the integration and peaceful coexistence among legacy applications, J2EE, and .NET. So what should you do in the meantime? For now, step back from the fray. Each vendor waves its flag about its Web services solutions, but performance, security, and other issues haven't been battle-tested.
Then prepare for the inevitability of detente among J2EE, .NET, and legacy applications. Look at how front- and back-end systems throughout the organization and along the supply chain must be integrated. Programming skill sets, existing infrastructure, tools maturity, and industry support must be balanced against the competing capabilities of J2EE and .NET. Few enterprises will exclusively embrace one technology, which means that because of (and despite) Web services, the world of the future will look as variegated as today's environment.
Finally, decide where Web services will be most useful and start implementing Web services projects there, whether they're based on J2EE or .NET. Standardize on Web services where it makes sense. And determine how to restructure business processes and supply chain relationships to take advantage of new Web services capabilities.
About the Author
Jake Freivald is the director of marketing at iWay Software, an Information Builders company and market leader in middleware that accelerates business integration. Freivald is responsible for developing and executing all of the solution marketing strategies. During his career, Freivald has held several managerial positions with Andersen Consulting and Prudential Life Insurance Company of America. He also served in the United States Marine Corps as a Signals Intelligence Officer. He can be reached at .
Back to top
|