Columns
Sun ONE: In the Framework of Java and Web Services
It seems as if Scott McNealy of Sun Microsystems has architecture envy. In response to Microsoft’s .NET framework for building Web services, he has debuted the Sun Open Network Environment. Still in its infancy, Sun ONE is Sun’s product strategy for building Web services using the Java platform. Of course, the big difference between the Java framework and the .NET framework is Java’s openness. There are dozens of vendors readying tools for the development and deployment of Web services applications, so you are not stuck with a single vendor’s solution.
Java is the language used to develop these Web services applications, and there are certainly a plethora of tools for developing Java applications, and just as many application servers available for deploying them. Theoretically, if the tool or server supports the Java 2 Enterprise Edition standards, you should be able to use it to build or deploy your Web services application.
Along with J2EE, Sun’s vision for Web services uses other open standards such as SOAP, UDDI, ebXML, and WSDL. If you don’t recognize these acronyms don’t worry—we’ll cover them in more detail in future columns. Without any third-party tools to help, you could write an application that used any of the aforementioned standards. It would be extremely cumbersome and painful, but it would be doable. This is one of those good news/bad news situations. The good news is there are APIs in development to make processing SOAP, UDDI, ebXML, and WSDL documents very easy. The bad news is that, today, Sun’s Java framework is kind of like a tomato…It’s smooth on the outside, but when you cut into it and look inside, it just doesn’t look done.
These API’s are on the way, but they will take time to get here. Until they are here, developing Web services applications with Java will be mostly an academic exercise. That’s OK, though. We all need time to get up to speed in this new way of writing applications and if it were ready today, it would just sit there not being used.
Sun’s Web services framework is divided into six layers as follows.
Service Creation & Assembly
Basically, this category contains development tools. In Sun’s case, these are the Forte for Java line of development tools, and other development tools for the C, C++ and Fortran languages. Other vendors have offerings in this space also, most notably IBM, with their VisualAge for Java tool.
Service Delivery
Sun sees a portal server filling this layer, specifically the iPlanet Portal Server. This layer sits between the user and the Applications & Web Services and/or Service Container layer(s). It’s nice to have, but some may elect to skip this layer altogether. IBM offers the WebSphere Portal Server to fill this layer.
Applications & Web Services
These are common Web services that Sun or another vendor might supply to be used to build your own Web services.
Service Container
Basically, these are your Web servers and application servers. Sun offers the iPlanet line (formerly Netscape) and this is where the largest third-party support for Sun ONE exists, with offerings from IBM and BEA to name but two.
Service Integration Platform
This layer holds software that allows Web services to connect to and integrate with legacy systems and other proprietary software such as ERP and CRM systems. Sun offers the iPlanet Integration Server to fill this layer which provides pre-built adapters for SAP, Siebel’s CRM suite and others. Undoubtedly, other vendors will follow suit with similar offerings.
Identity & Policy
No Web services framework would be complete without some way to identify users and control access to the Web services. Sun offers the iPlanet Directory Server (an LDAP server) for this purpose and many other LDAP implementations exist.
Earlier, we stated that with Java Web services, you are not stuck with a one-vendor solution. This doesn’t mean that a one-vendor solution is bad though. The more vendors you throw into the mix, the more chance you have for incompatibilities to pop up, even with software that adheres to open standards.
Certainly if you went with Sun’s version of Web services using the Java platform, known as Sun Open Network Environment, you would be assured that everything would fit together nicely. You would essentially then have a Sun version of .NET with no vendor independence, but you would still have hardware independence.
Well, that’s about it for now. Have a Happy New Year and look for another column after said New Year.