Monday, August 14, 2006

Issues with system integration

Systems integration refers to the work of gluing together independent applications, services, and data stores.

4 Levels of Integration
Data Level Integration: it's the simplest architectural pattern for systems integration and the quickest to implement by sharing access to an enterprise data store with one or more other applications.
Message Level Integration: it's the most flexible and best performing of the system integration patterns. Data is packaged and transmitted over the network asynchronously for remote processing.
Procedure Level Integration: it's an extension of message level integration that supports synchronous interaction between system. It's generally referred to as remote procedure calls (RPC) or remote function calls (RFC).
Object Level Integration: it can be used between systems that support a common distributed object architecture, such as CORBA or DCOM, in which some well-know objects act as intermediaries between client and server software object. This intermediary (ORB in CORBA) provides a set of services that clients can use to locate a desired server and invoke it. Once the client locates the service, the server object provides a remote stub of itself to the client that it can use locally. On the server side, there's a client skeleton providing the same proxy functionality to the server object.

SOAP
The SOAP specification addresses 4 main areas: message envelope, encoding rules, RPC support and HTTP binding. A basic SOAP message contains SOAP envelope (the wrapping structure), SOAP header (which contains meta-information specific to a SOAP message itself), SOAP body (which contains the payload of the message, such as an application specific request, response, or an asynchronous message). Both the header and the body can be further structured into SOAP blocks. SOAP can be extended to accomodate non-SOAP attachments to basic SOAP messages.

WSDL
A WSDL file contains 5 groups of information:
(1) data types: the <types> element allows you to derive new XML Schema data types for elements used in your WSDL descriptions.
(2) messages: the <message> element defines messages including parameters.
(3) port types: the <portType> elements are abstract constructs that allow grouping of message definitions into operations. They define request/response interaction without regard to the specifics of the protocol used to exchange the messages.
(4) bindings: a <binding> element maps a port type to a communication mechanism, like SOAP.
(5) web service instances: a <service> element describes an instance of a web service, including where it is located (URI), what its interface is (port), and how to interact with it (binding).

No comments: