Borland has announced Borland Janeva 6, the latest version of the company's platform interoperability technology. Janeva enables developers to integrate between their J2EE, .NET, and CORBA code bases. The new release will contain enhanced security and transactional support, will integrate with more J2EE servers, and new callback support.
- Posted by: Dion Almaer
- Posted on: November 12 2003 11:22 EST
New Features in Janeva 6
- Client authentication with username/password
- Identity delegation in ASP.NET
- SSL for clients and servers
This release is certified against the following application servers
- Borland Enterprise Server 4, 5 & 6
- BEA WebLogic 7.0 and 8.1
- IBM WebSphere 5.0
- Oracle9i Application Server Java Edition v9.0.3
- CAO model support for EJBs: This release supports the CAO pattern abstraction over the EJB factory pattern
- J2EE and CORBA applications can also utilize new callback capabilities to 'talk back' to .NET Framework-based applications for two-way interoperability
- Configuration model: This release supports a new configuration model for Janeva that uses the application config file.
- .NET Remoting Well Known Server Type: .NET Remoting style servers using the WellKnownServerType model are supported.
- .NET remoting transient and callback objects: .NET Remoting style transient objects and callback objects are supported
- Visual Studio .NET 2003 support (In addition to existing support for Borland C#Builder and Visual Studio .NET 2002)
- This release has integrated API documentation with Visual Studio.
- Server support: Full OMG Portable Object Adapter based servers are supported.
- Portable Interceptors: Request Interceptors based on the OMG Portable Interceptors specification are supported
NOTE: Some news sources are claiming that Janeva 6 is released. This is an announcement, with the actual full release expected at the end of the year
Press Release: Borland Raises the Bar for Platform Interoperability: Launches Borland Janeva 6 to Support Mixed IT Environments at Reduced Risk and Cost
Borland's Janeva 6 Integrates .Net, Java, CORBA Apps
Borland Connects The Dots Between .Net, Java Apps
Borland updates Janeva
Borland Upgrades Janeva
- Borland Announces Janeva 6 by Mileta Cekovic on November 12 2003 14:22 EST
This is actualy the second version of Javeva, I suppose the number 6 is to align it with the upcomming VisiBroker 6 and Borland Enterprise Server 6.
It is probably the first real version of Janeva, as the first version was lacking some serious functionality (POAs on .NET side and callbacks).
Still, connection .NET clients to J2EE/CORBA backends is the right choice for many distributed applications. This SOAP/WebServices crap is not for big enterprise systems under heavy load. It is not supprise that Intel is one of the main WebServices supporters as parsing and marchaling all this bloated SOAP messages is CPU cycles hungry. Very, very much hungry.
My tests show that WebServices communication is from several times to an order of magnitude slower than native RPC like CORBA/RMI/.NET Remoting/DCOM.
If the contracts are written so that soap messaging framework has significant influence on overall performance then maybe you shouldn't be using any kind of remoting at all. As one very smart guy wrote, first rule of distributed systems is "don't". But if you do, design messages so that SOAP vs RMI overhead is not detrimental. That said, SOAP stack should not be by order of magnitudes slower than RMI, and it should scale same (or better, since it forces you to rethink interaction in terms messages that don't assume in-memory state between them).
I agree with you, but there are situations when you need to distribute your application. The very smart guy that wrote the first rule of distributed systems design also wrote the examples of the sitations when you need to distribute, ;) (Martin Fowler, Patterns of Enterprise Application Architecture).
And when you need to distribute you need to reduce the number of RPCs as well as the amount of data that need to be interchanged (the second rule of distributed systems design).
And also, when you need to distribute and you have reduced the number and the 'weight' of the RPCs, use RPC framework that suit your needs. Don't use bloated SOAP for tigthly coupled intranet LAN or WAN applications (the third rule of distributed systems design, ;) ), and rethink twice if you can avoid it for communication over Inernet. All modern native RPC mechanisms like CORBA/RMI/.NET remoting have HTTP tunneling so firewall is not a very big issue (you still need to configure for HTTP tunneling though). At the end, there are not so many situations where you need to use WebServices/SOAP.
Let's ask a simple question to validate this argument. Replace the .NET client environment with a Java client. Would you still recommend using the same approach for connectivity (including the necessary rethinking of the interactions)