CORBA versus Web Services

CORBA versus Web Services

SOA Architecture principles:

• Need decoupled tiers in a SOA solution to enable flexibility and interoperability

• Need to support abstraction and interoperability of the service at both the Specification level and at implementation level (CORBA is just at the implementation level)

• Need to be independent of the various versions of vendor OS and object code (implementations)

• Vendor specific optimisation of the service interface needs to be preserved independent of the implementation

• Interoperability must support security and transaction management in the service

• Support service integration that is independent of the application implementations

• The standards must support the data volumes and SLA timings required and are scalable

• Support widespread common standards and vendor strategies that are industry wide

• The Service specification and implementation must be independent of any single Vendor. The Vendor application should not have to implement specific

• The change management of a service should only affect the specific service implementation and not all the consumer and producer users of the service

• A change in a service should be at the service tier abstracted away from the physical implementation

• The service needs to be decoupled from the message and channel endpoint ID (Ifaps, Interface ID, Format, Protocol) (In CORBA/IIOP it uses Interoperable Object Reference (IOR). IORs contain addressing information in a portable format which any CORBA product can resolve to an object endpoint.)

• Multiple queue management is supported by the API.

• Support standards that are industry specific

• Support standards that work in a federated internet environment

• Support standards that are inclusive of Java, non-Java (.Net) environments and other legacy systems.

• Use an adapter strategy that is independent of the endpoint description defined in the service. A service does not identify the specific API object in the endpoint identification. Hence the Service is independent of the API access method foe true decoupled integration from the service method. Otherwise every API call would have to describe the object and endpoint required in its implementation. Using Web services, the call is independent of the API adapter implementation. The service is defined at the specification level and implementation level.

Web services note

Web services is HTTP, XML, SOAP, WSDL, UDDI and WSFL

In web services the SOAP is basically a HTTP request and response that complies with the SOAP encoding rules. The SOAP endpoint is a HTTP-based URL. Unlike CORBA , SOAP does not require that a specific object is tied to a given endpoint.

The web services stack offers SOAP as the open standard ORPC for mapping application objects to network protocols. SOAP is not tied to a specific transport protocol , HTTP has become a favourite.

Endpoint naming is URL

Interface / Object - multiple - WSDL

HTTP and XML support a distributed service model

CORBA note

Basic RPC Architecture

In both CORBA and DCOM interactions between a client process and an object server are implemented as object-oriented RPC-style communications.

To invoke a remote function, the client calls a client stub. The stub packs the call parameters into a request message, and invokes a transport protocol to ship the message to the server. At the server side, the transport protocol delivered the message to the server stub, which unpacks the request message and calls the actual function on the object. (Stub and Skeleton in CORBA)

Java SDK does come with CORBA

Vendors competed with ORB specs and this broke down to idea of interoperability between the requester and the provider.

CORBA uses a binary format to pass data. This is more efficient than encoding values in text (more bulky). The problem can be that Firewalls block CORBA messages. Firewalls can be configured to work with CORBA.

SOAP required 10-15 times more bandwidth than IIOP (even 50 to 100 times if using structured or unions in web services) and is slower that IIOP and uses more processing power to parse the XML from human readable decimal. (IIOP from CORBA uses 64 bit hexadecimal.)

In CORBA every application would need to run same ORB product.

E.g. integrating Legacy using Java RMI/J2EE making CORBA not necessary

CORBA does not handle security and transaction management well

CORBA can handle server to service integration but not good at

Gartner View point

Generic IFaPs are the key to loosening the coupling (virtualizing) the performance and the performers

SOA = modular + distributable + shareable +loosely coupled

But too many SOAs are top-down

WOA = SOA + WWW + REST

Globally linked Uniform IFaP interfaces

Explicit representation Middle-out is an architectural style that enables decentralized change through the following minimal constraints:

• Generic solutions — Underlay a wide range of unexpected uses

• Simple interface — Minimal specification of easily applied identifiers, formats and protocols

• Federated components — Overlay a wide range of unexpected implementations

• Extensible — Easy and dynamic forward and backward compatibility

There are two competing approaches to SOA

• SOA = modular + distributable + shareable + loosely coupled

• Two different approaches to "simple interface"

• WOA = SOA + WWW + REST

• WS-* = SOAP + WSDL + UDDI + ESB

Using WS* should seek to use WOA principles were ever possible.

• Replace (or wrapper) application-specific identifiers with URLs

• Focus relentlessly on uniformity/generality

• Uniform identifiers (MDM and CDI)

• Uniform formats (look to RSS, Atom and GData for inspiration)

• Uniform operations (salesforce.com 17 verbs, WS-ResourceTransfer)

• Focus on the representations, not how they are sent over the wire

• The key to SOA is 80% information architecture

• Think of XML representations as containing not just data, but control as well

• Make what was implicit or out-of-band between client and server explicit in the representations they exchange

• If you really want shared services, architect for serendipity, not specificity

#SOA #EnterpriseArchitecture #ArchitectureGovernance