Web services VS CORBA|J2EE|etc.

SOAP services background

Lets start from discussing the name “Web Service”. When do we think what word “WEB” really means?

Personally I cannot give exact definition of the term: WEB. It is just associated with something big, open, friendly, browser accessible, interesting, human readable and targeted to people (me).

Technically speaking term “Web Service” is a shortcut to XML/SOAP/WSDL/UDDI collection of technologies. Lets try to define that collection:

It is targeted to comp-2-comp communications (targeted not to people)
It is not accessible via browser
It is not interesting

Hmm, that definition does not match to my feelings, which are associated with the word “Web”.

I think that name “Web Service” is very misleading and it was invented to promote XML based technologies.

I may look like Web Services opponent, but I am not WS opponent in reality. I just want to clearly define place of the technology and promote unbiased look at any technologies. And I play devil’s advocate sometimes.

An interesting article (Kicking out the Cuckoo by Edd Dumbill) regarding this issue can be found at http://www.xml.com/pub/a/2002/04/24/taglines.html

Another interesting reading to clean up our brain from XML propaganda may be found at (note: it is not my opinion):

http://www.pault.com/X/987224675/addPostingForm

So, let me use name SOAP-service instead of Web Service to remove magic of word “Web”.

Realizing the fact that we are dealing with comp-to-comp calls we may use even more precise term: XML-RPC (XML based Remote Procedure Call). SOAP has started as XML-RPC and it is so in its basis and it is going to be primary usage of the technology.

Usage of proper names is extremely important and promotes better and unbiased understanding of things around us.

When we hear word RPC, it may cause completely different associations:

It is boring. CORBA, DCOM, RMI, MQ Series hey! Why do we need yet another one?

If it is boring, it is impossible to sell for masses, so …

Lets look at biggest selling point of SOAP-services: Interoperability.

It does mean that we have something working just fine and we just want to call something different than we have. In other words: we need an “Interface” technology. As we go to area of common agreements we compromise something: flexibility, feature richness, performance etc. There is no way to have one thing that will satisfy everybody. There will not be one OS, one language, one IDE, one editor etc.

This leads us to recall that we need an “Implementation”. That is. Lets not forget about old boring stuff: writing of actual implementation of business logic, database connections, DB schemas, emails, and all “not so exited” things which are essential for doing business.

Lets say this: DB schemas and data in DB are vital things for businesses everything else is just interfaces. Yes, of course, BUSINESS LOGIC! But it can be (re)implemented/duplicated with many languages, may have bugs, to be ugly etc., and it may be good enough till DB and data is OK.

By no means I neglect business logic implementation and interface technologies, I just want to reset priorities. All those OO concepts, languages, interface technologies are important only when they allow manipulating our data more efficiently.

Things to keep in mind:

“standard” does not mean “suitable in all cases”. Even more: in order to be efficient we must break standards. It is some kind of art to decide where standards stop to work efficiently and what we should develop ourselves.
every thing has limits of applicability.
Car example: an excellent chassis + engine may be used to build a coupe, a sedan, a pickup but cannot be used to create even light battle tank.
Beautiful appearance and marketing hype does not mean “good product”
“Good product” does not mean it is good for every appliance.

That was a background. Lets look at technologies and their applicability and goals.

RPC needs coverage by different technologies.

First lets look at RPC needs coverage by different technologies.

As we may see some technologies are trying to cover different aspects of RPC problem.

Typical enterprise computing services.

Second comparison of technologies might be done against typical enterprise computing services.

As we may see some technologies are trying to satisfy all our needs and other address only certain areas.

One interesting service is “Externalization” that means ability to accept data feed from different sources in different format. Not surprisingly that CORBA and J2EE uses that service to implement, well, SOAP data connector. That is. J2EE business logic implementation (Session Bean) can be called via SOAP, IIOP(CORBA), and RMI in the same time concurrently with full support for life cycle management.

That looks like there is no contradiction between J2EE|CORBA|SOAP. That is pretty much so. SOAP-services define just interfaces and does not have any idea about implementation.

However, that is not true for many vendor implementations. XML hype seems to be used to sell vendor specific implementation frameworks. Those vendors try to sell their products as implementation platforms (sometimes they name it as universal hub to plug in any other solutions, we hear that many times, right?) Lets take Systinet (http://www.systinet.com ) as an example:

<QUOTE>

Systinet makes it easy to build, deploy, secure, and manage Web services.

Systinet's products are based on industry standards such as XML, SOAP, WSDL and UDDI. Our products interoperate with other Web services solutions such as .NET and are portable across a wide variety of platforms and servers.

Businesses use Systinet's solutions to integrate existing applications, create new 'integration-ready' applications, and securely connect with business partners. Also, ISVs and OEMs embed Systinet's technology to enable their products with Web services.

</QUOTE>

I would say that is not different than CORBA frameworks, except CORBA standardized much more details than SOAP – services.

SOAP vs CORBA

It makes sense to compare SOAP/WSDL/UDDI with CORBA, rather than with J2EE. At current stage J2EE is an implementation/extention of CORBA (common object request broker ARCHITECTURE) for Java platform that extends CORBA with implementation standards.

So, lets try to create SOAP vs. CORBA comparison table. This table mostly comes from presentation of “The Comparison of CORBA and SOAP” by Fei Sophie Gao, ITSC UAH, February 28, 2002 with my comments and additions.

CORBA

SOAP

Cross-platform Support

1. CORBA1.0 gave no implementation for ORBs, and then was difficult to work with firewalls.

2. CORBA2.0 introduced the Inter-ORB Protocol (IIOP) which runs over TCP/IP.

3. CORBA extends itself to include the Web

Being based on Internet specifications, SOAP can plugs into existing Web environments; thus it is supported on any computer platform.

Transmission Data Format

1. CORBA uses binary encoding for data transmission.

2. It assumes that both the sender and the receiver have full knowledge of the message context and does not encode any meta-information.

3. This approach results in good performance, but makes it hard for intermediaries to process messages.

(We do not need extra Metadata as soon as we have reached agreement.
Metadata can be pulled out of repository on demand if necessary.
Client can create CORBA messages dynamically.)

1. SOAP uses XML to encode messages, and is easy to process messages at every step of the invocation process.

2. The ease of debugging SOAP messages leads to a quick convergence of the various SOAP implementations.

I think that is matter of desire, agreement and public support rather than advantages of human readable format.

Are there problems with MP3 support from different implementations?

Interoperability

1. CORBA 1.0 has problem with being unable to build a system of interoperable ORBs implemented by different vendors.

2. CORBA 2.0 resolves the problem by defining a single wire-format to guarantee that two separately developed CORBA implementation work together

Being based on ~~HTTP protocol and~~ XML format, interoperability is easy between different SOAP enabled computer systems.

Scalability

1. CORBA features a simple mechanism to use stateless ORB requests.

2. The choice of stateless or stateful is decided by the system designer.

1. The HTTP protocol is stateless.

2. ~~SOAP server can maintain state for the client using cookies, or special object identities within the SOAP calls.~~

3. SOAP is going to have a session mechanism to enable transactional requests.

Note: “statelessness” does not guarantee scalability and even may be a cause of performance degradation.

Object Identity and Lifetime

1. A particular instance of a

CORBA object is identified by an object reference.

2. CORBA is used for transparent communication between application objects.

1. SOAP doesn’t mandate any object identity other than an URL endpoint.

2. Life time of SOAP objects on the server becomes an issue if the server is maintaining state.

3. The server needs to timeout the object to reclaim its resource.

In short: No life cycle management.

Protocol Transports

1. CORBA2 implementations use Internet Inter-ORB Protocol (IIOP), which is GIOP (General Inter-ORB Protocol) over the TCP/IP.

2. An additional protocol, called the DCE CIOP (DCE Common Inter-ORB Protocol) is also supported by CORBA2.

The protocols are required to FULL CORBA support, CORBA server may be called with other protocols via Externalization facility.

1. HTTP is defined as the protocol for transmitting method calls.

2. Other transports such as SMTP are not inconceivable, which requires the SOAP method calls to be unidirectional.

SOAP does not define wire protocols that is up to implementation.

Security

1. The CORBA Security Service provides a security architecture that can support a variety of security policies to meet different needs.

2. The Service specifies authentication, authorization, and encrypting of messages.

1. At the lowest level, SOAP messages can be passed over HTTPS to prevent snooping, and that the client and server can verify each other's identity.

2. A standard called XML Key

Management Specification (XKMS) is under development to provide finer grain security that is necessary to authenticate particular users of specific Web services.

Easy to Use

Being based on a distribution of clients and servers makes CORBA complex when getting things started.

1. HTTP and XML make for easy

implementation and debugging .

2. Text-based representation of information allows for easy deciphering of method calls and returns results. (Those are common words but I do not consider them to be a valid argument. It is for a bit easier debugging ONLY!)

Limitations

CORBA 1.0 The solution built on CORBA protocols is dependent on a single vendor’s implementation. Thus, every node in the application environment need to run the same ORB product, decreasing the interoperability. CORBA 2.0 resolves the problem by defining a single wire-format to guarantee that two separately developed CORBA implementation work together

Some firewall issues (laziness to open standard IIOP port)
We MUST have CORBA implementation framework to start to work with CORBA

SOAP lacks some tools common for CORBA, such as transaction management, etc. (I would separate development time tools and runtime services. Actually, there are tools available, but again, SOAP does not define or imply them. And much less runtime services are available)

J2EE

That is already big document, but I have decided to add something about J2EE here, because in case of separate document it will have significant overlap with this one.

Lets make it clear:

JVM is OperationSystem.

J2EE compliant Application server (container) is a framework to build BUSINESS applications.

Value of J2EE for business programming comes not only from APIs, but also from the way they are put together and from set of recommendations for developers and assumptions about nature of business programming.

That is, J2EE is supposed to be a collection of best practices in business programming.

Suitability of J2EE for companies should be evaluated from several positions:

Is J2EE business model compatible with our business model?

Are we ready to study(!) and apply best practices? That is probably main issue that prevents companies from adopting J2EE. In order to be effective developers MUST understand the technology and its limitations. That is quite different from other widely used approaches:

Do not tell me how to program! I know what I am doing!
Belief that with THE tool (wizard) even novice developer will be able to produce enterprise scale/quality application.

#2 is almost incurable.

#1 is temporary - most developers overcome that. If they will take a time and study other than own approaches, they see that “nothing new under the Moon” and many their problems already have proven and well-known solution.

Another important concern is a cost of application servers. It is not an issue if even simplest cost analysis will be done. With inexpensive entry level application servers like JBoss( $0 ) and JRun cost of app server is not an issue any more.

Because J2EE platform is based on CORBA it enables easy interoperability with any enterprise solutions and SOAP exposure allows communicating with MS products relatively easy (painlessly if MS products should call J2EE services).

As far as I know <COMPANY's> business model I think that J2EE programming model is quite suitable for NAIC.

Great deal of flexibility and openness of J2EE platform allows leveraging existing applications and smoothly migrating to “new architecture”.