email article printer friendly get the code more resources

WebLogic and .Net: Building a Web Service
Your company wants to build Web services, but you've got a heterogeneous computing environment. Find out how you can achieve true interoperability
by Heinrich Gantenbein

Posted June 25, 2004

It didn't take long for the major software vendors to realize that none of them would dominate the enterprise platform market. Thus interoperability became a necessity.

The software industry has attempted interoperability with various technologies (see sidebar "A Brief History of Interoperability.") However, one shortcoming of these efforts was that they pretended that you could treat remote objects the same as local objects, which just isn't the case. Additionally, parameter type compatibility would imply semantic compatibility and no provisions were made to allow systems to be composed of building blocks for service level agreements (SLAs). So something more was needed.

Then Extensible Markup Language (XML) emerged as a data expression language, and a more service-oriented architecture for software development was born. These developments lead to Simple Object Access Protocol (SOAP), Web services, and all of the WS-* standards. Additionally, the Web Services Interoperability (WSI) organization was created to ensure compliance to the standards. The major industry players (including BEA and Microsoft) embrace standardized XML and SOAP-based Web services. Does this mean that true interoperability is possible today?

Follow us as we show how you can build a Web service using Microsoft .Net and BEA WebLogic in a standards-compliant way. Let's start with some service-oriented architecture (SOA) basics.

SOAs and Web Services
SOAs implemented as Web services are fundamentally different from object-oriented architectures (like CORBA and Java RMI). They are also different from component-oriented technologies such as COM and DCOM. COM+ and J2EE session beans exhibit some elements of SOAs, such as loose coupling, SLAs, and SLA composition.

Service-oriented architectures require that all contracts be validated, either structurally and semantically with schemas (XML Schema Definition [XSD]), Web Service Definition Language (WSDL), and Business Process Execution Language for Web Services (BPEL4WS), or with SLAs through WS-Policy and related standards.

Web services may be composed of other Web services, and Web service SLAs may be composed of other multiple policies. Web services also are standards-based and must be loosely coupled, which means they are message-based and platform-independent. Failure scenarios are expected.

The access to Web services is coarse-grained because of the potential cost of a round trip. No access to individual fields in the "object" is allowed, and Web services have few interface methods with large amounts of data.

Figure 1 shows an overview of today's Web services standards. These standards are changing rapidly.