Service-Oriented Architecture Introduction, Part 2
A service-oriented architecture is one that has a robust service layer. The services in the service layer have the ability to be invoked over a network. The technologies used to invoke the interface of the services stress interoperability. The services in the service layer also stress location transparency so they may be discovered and used dynamically. Most companies have already built components with many of these properties. They are some of the things to keep in mind when designing services or harvesting existing components to be service-enabled. Services can be built using a large number of technologies from application servers like .NET or J2EE, middleware solutions, or even adapters for database systems that enable access to data via Web services. In this article, I will provide some additional details on the properties of a service and how those properties are satisfied by Web services.
Properties of a ServiceThe services in the business logic layer have the ability to be invoked over a network. The technologies used to invoke the interface of the services stress interoperability. The services in the service layer also stress location transparently so they may be discovered and used dynamically.
Invokable Over a NetworkOne of the properties of a service is that it must be invokable across a network. There are many different ways you can accomplish this. A Java Servlet that takes a request and gives a response is a good example of an invocation of a service across a network. The way that services are invoked depends on two things, the transport type and the payload format.
Transport TypeThe transport type is the protocol that is used to transfer data from your client to your service. A Web server uses Hypertext Transfer Protocol (HTTP) to transfer data. HTTP is also used with Web Services to transfer service requests. The benefit of HTTP is that requests to a service are not blocked by company firewalls. A request that is transferred via HTTP is the most interoperable of all protocols because of the firewall issue. However, there are a huge number of transport types that can be used for service invocation. The attributes of the service you are building will determine the most appropriate transport type.
Payload FormatThe payload format is the format of the data that is transmitted from a client to a service for method invocation. In most cases, the request data must contain both the service that the client wishes to invoke as well as the arguments for the method. Extensible Markup Language (XML) is the most popular format for data exchange. It is a text-based format that uses tags to delimit data elements in an XML document. Due to its popularity, it is the most interoperable of all data formats. Although XML is the most well understood data format, any number of other formats may be used for service invocation.
InteroperableInteroperability is the ability of the service to be invoked by any potential client of the service. If you are building an internal application and all of your clients run Java, then your service may use only remote method invocation (RMI) to be invoked. However, if your clients will include those on the Internet, then you will probably want to have your service invoked via Web Services. In addition, other adapters can be written to allow your service to be invoked using other methods such as IIOP or via MQSeries simultaneously. Below is a diagram depicting a possible architecture for a service.
A client should be able to invoke your service using more than one protocol type at a time by using adapters. A client should also be able to invoke your service using more than one payload type. For example, you could invoke a service method using a fixed length record, XML and Java Objects for the payload type all at the same time. Since your service is interoperable, if a client needs to invoke your service via carrier pigeon, then you need to figure out how to write a carrier pigeon adapter for your service.
Discovery and LookupDiscovery and lookup is another property of a service-oriented architecture. Discovery and lookup refers to the ability of a client to lookup services that match its needs in a dynamic fashion. For example, a client might need to validate a credit card. The client needs to be able to go to a third-party directory to discover all of the services that can provide credit card validation. The directory also stores information about the service. The information includes the location of the service and how the service must be invoked. The directory contains the methods that the service supports such as the arguments that must be passed as well as the argument types.