A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification.
The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification.
DCOM is the acronym for the Distributed Component Object Model, an extension of the Component Object Model (COM). DCOM was introduced in 1996 and is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation’s DCE-RPC spec and will work with both Java applets and ActiveX components through its use of the Component Object Model (COM). It works primarily with Microsoft Windows.
CORBA is the acronym for Common Object Request Broker Architecture. It was developed under the auspices of the Object Management Group (OMG). It is middleware. A CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.
The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architectures.
The Object Request Broker (ORB) is middleware that uses the CORBA specification. The Object Request Broker or ORB takes care of all of the details involved in routing a request from client to object, and routing the response to its destination. The ORB is also the custodian of the Interface Repository (abbreviated variously IR or IFR), an OMG-standardized distributed database containing OMG IDL interface definitions.
On the client side, then, the ORB provides interface definitions from the IFR, and constructs invocations for use with the Dynamic Invocation Interface (DII). It also converts Object References between session and stringified format, and (for CORBA 2.4 and later ORBs) converts URL-format corbaloc and corbaname object references to session references.
On the server side, the ORB de-activates inactive objects, and re-activates them whenever a request comes in. CORBA supports a number of activation patterns, so that different object or component types can activate and de-activate in the way that uses resources best.
The OMG Interface Definition Language (IDL) permits interfaces to objects to be defined independent of an object’s implementation. After defining an interface in IDL, the interface definition is used as input to an IDL compiler that produces output to be compiled and linked with an object implementation and its clients.CORBA (There are other uses of the IDL initialisms. For example, there is also a Java IDL.)
Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered. This section provides information on the specification of services.
The technology of Webservicesis the most likely connection technology of service-oriented architectures. Web services essentially use XMLto create a robust connection.
The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined is explained in WebServices. A service provider can also be a service consumer.
SOAs come with a full bag of promises, to:
- Dramatically speed up the application development process
- Make applications and systems more adaptable
- Make IT more agile in responding to changing business needs
- Provide the framework to align IT with the Business
What an SOA does is deliver a way to create a standard messaging protocol and interface that, once engineered into applications, improves the ability to move data between applications and databases in a more seamless fashion, and that’s a good thing.
As inevitable the rub comes when trying to implement SOA with legacy applications that were designed and developed without an eye towards exchanging data anywhere but within the internal architecture and even then though gateways and the like. So as much as the literature encourages reusing existing applications, in reality the real benefits of SOA come when the environment is designed with that architecture in mind. Therefore for most organizations, the migration to SOAs will be evolutionary in nature. As new initiatives are pursued and legacy applications replaced they can be done so within an SOA framework.
As software suppliers integrate SOA into their product offerings SOAs will begin to flourish and, like SQL compliant DBMS, Object Oriented Programming tools will become commonplace. Traditionally this is a 7- to 10-year cycle, not 3 to 5 years.
Still while technology tools enable us to do things faster, cheaper and better the challenge is to deploy them in a mature and intelligent way that continues the leverage the organization’s ability to sustain growth and deliver value to stakeholders; used in that context SOAs hold much promise.