|
The boundary of the two major SOAP camps is simply language/platform. When
working with J2EE, you're developing your Web services in Java, and they can
be deployed in a suitable J2EE server. When working with .NET, you're
developing your Web services in VB, C#, or some other .NET-compatible
language, and they can be deployed on a .NET-compliant operating system
(Windows XP or Windows 2000). (I bristle a bit at the term "camps". I don't
feel a sense of battle. The two groups are working very well together to
advance the technology.) Most SOAP implementations (aka SOAP runtime
servers) support all of the above listed technologies. Some of the older
implementations don't support WSDL and UDDI. Some support only a subset of
the XML Schema type system. These inconsistencies currently make
cross-platform interoperability a little bit challenging, but these issues
will be short-lived. Within the next 3-6 months, most of the basic
interoperability issues will be resolved.
The idea is that you can use any SOAP implementation to create a Web
service. You describe the service using WSDL. You register the service in
UDDI. A consumer finds the service in UDDI, locates the WSDL description,
creates a client interface to the service from the WSDL (using any SOAP
implementation), and communication happens.
The differences between SOAP runtime servers is somewhat equivalent to the
differences between J2EE application servers. From 50,000 feet, they all do
essentially the same thing.
|
