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 Service
The 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 Network
One 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 Type
The 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 Format
The 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.
Interoperable
Interoperability 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 Lookup
Discovery 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.
Web Services
Web Services is a specification for service invocation that includes HTTP as the transport type and a specially constrained version of XML called SOAP. SOAP (Simple Object Access Protocol) is a way of constructing an XML document in a format with a standard header and body. In a Java implementation, Java Servlets are used to accept HTTP requests on a network. Java Servlets that accept SOAP documents are also Web Services.
Implementing a Web Service
Web Services only specifies the way that is service method is invoked. It does not specify the way that the business logic for the service is implemented. A Java stateless session bean is one of the best ways to implement this business logic for use in a services architecture. A stateless session bean is a component that runs on a Java Application Server. The stateless session beans methods can be invoked across the network. They are invoked via Java Remote Method Invocation (RMI). This method of invocation is not very interoperable. Both the client and the server must be Java applications because the data is transferred via serialized Java objects. Also, the data cannot be passed through firewalls.
Interoperable
To solve this interoperability problem, tools from BEA and others allow the publishing of Web services from stateless session beans. These tools automatically generate a servlet that takes in a SOAP request, a proxy that the client can use to invoke the servlet and WSDL (Web Services Description Language) descriptions of the format of the interface. After your stateless session bean is published as a Web service, the component has two different transport types and two different payload formats. The service may still be invoked via RMI as well as HTTP/SOAP at the same time. Both of these methods of invocation meet the requirement of a service to be invoked across a network.
Discovery and Lookup
Web services uses UDDI for discovery and lookup of services. UDDI stands for Universal Description, Discovery and Integration. It provides a registry for information about services, including a service’s location and information on how to invoke the service. Web Service Definition Language (WSDL) is used by a UDDI directory to store information about services. WSDL is an XML schema that describes service interfaces, transport types, and locations. Other directory types may also be used for the same purpose.
Conclusion
All of the properties of a service-oriented architecture are supported by Web services. The J2EE Platform is a great way of implementing a service. By creating a robust business logic layer of services, an organization can achieve huge benefits. In my next article, I’ll explore those benefits in some detail.
About the Author
Michael Stevens is an independent consultant specializing in service-oriented architectures for the enterprise. He has over fourteen years of experience in information technology architecting and developing software systems, most recently focusing on J2EE solutions. He founded a software company that developed solutions for the mailing industry. He is a certified Java programmer, a member of the IEEE Computer Society, and of the ACM. He may be reached at mike@mestevens.com.
