In IT Industry the use of different technologies and applications is a reality. At a time when resources are scarce, IT shops cannot just throw away their existing applications; rather, they must leverage their existing investments. Service-Oriented architecture (SOA) is popular because it lets you reuse applications and it promises interoperability between heterogeneous applications and technologies.
Now I will introduce SOA from a Java developer perspective and examine the technologies available in the Java space to build service-oriented applications.
What is SOA?
Service Oriented architecture is abbreviated as SOA.SOA is an architectural style of building software applications that promotes loose coupling between components so that you can reuse them. Thus, it’s a new way of building applications with the following characteristics:
XML and the Simple Object Access Protocol (SOAP) are the enabling technologies for SOA, since they’re platform-independent standards.
Service is the basic building block of SOA. A service is a self-contained software module that performs a predetermined task: “verify a customer’s credit history,” for example. Services are software components that don’t require developers to use a specific underlying technology. As Java developers, we tend to focus on reusing code; thus, we tend to tightly integrate the logic of objects or components within an application. However, SOA promotes application assembly because services can be reused by numerous consumers. For example, in order to create a service that charges a consumer’s credit card, we build and deploy only one instance of such a service; then we can consume this service from any number of applications.
The other key advantage of SOA is that it lets you automate business-process management. Business processes may consume and orchestrate these services to achieve the desired functionality. Thus, new business processes can be constructed by using existing services. For example, a customer order that has been submitted to shipping can be represented by a business process that can asynchronously interact with the requisite services.
Why SOA?
Using SOA offers several key advantages. You can:
SOA and Java
Most developers often think web services and SOA are synonymous. Many also think it’s not possible to build service-oriented applications without using web services. To clarify, SOA is a design principle, whereas web services is an implementation technology. You can build a service-oriented application without using web services–for example, by using other traditional technologies such as Java RMI.
The main theme behind SOA is to find the appropriate modularity and achieve loose coupling between modules. You can build an application where the modules don’t have too much tight coupling between interacting components, such as an application where the JSP presentation layer is not tightly integrated with the data model and accesses it appropriately via an EJB.
It’s worth mentioning that Jini Technology had long established the concept of SOA prior to the rise in popularity of web services. What web services bring to the table are the platform-independent standards such as HTTP, XML, SOAP, and UDDI, thus allowing interoperability between heterogeneous technologies such as J2EE and .NET
Different Layers for Service-Oriented Applications
The Service Layer
As we discussed earlier, services are the building blocks of service-oriented applications. Thus, services are somewhat analogous to Java objects and components such as EJBs. Unlike objects, however, services are self-contained, maintain their own state, and provide a loosely coupled interface.
The greatest challenge of building a service-oriented application is creating an interface with the right level of abstraction. On creating the service layer the following points should be considered.
Top-down approach: The top-down approach requires that you identify and describe the messages and operations your service provides and then implement the service.
The bottom-up approach : It quite popular because it lets you reuse your existing investment in business components. For example, vendors provide the tools that let you expose a PL/SQL-stored procedure that checks whether a customer is entitled to a discount as a service.
The most important aspect of a service is the service description. When using web services as the implementation technology for SOA, Web Services Description Language (WSDL) describes the messages, types, and operations of the web service, and is the contract to which the web service guarantees it will conform.
Building the Service Layer in Java
Java provides a comprehensive platform for building the service layer of service-oriented applications J2EE 1.4 standardizes the APIs for building web services using Java.
The following table provides the list of APIs available in the J2EE 1.4 to build web services applications.
Java APIs
Description
JAXP
Java API for XML Parsing
JAXB
Java API for XML Binding
JAX-RPC (JSR 101)
Java API for XML-Remote Procedure Call
SAAJ
SOAP API for Attachments in Java
JAXR
Java API for XML Registries
JSR 109
Web Services Deployment Model
EJB 2.1
Stateless Session EJB Endpoint Model
We’ll discuss building the service layer of an SOA application in a future article.
At first glance, most SOA vendors are easing developers’ workloads by providing the appropriate design tools. For example, Oracle offers web service design facilities within the Oracle JDeveloper 10g IDE, and IBM’s WebSphere Application Developer Studio simplifies SOA development.
Business Process Layer
The main benefit that SOA brings is the standardization of business process modeling, often referred to as service orchestration. You can build a web-service-based layer of abstraction over legacy systems and subsequently leverage them to assemble business processes. In addition, SOA platform vendors are providing tools and servers to design and execute these business processes. This effort has been standardized by an OASIS standard named Business Process Execution Language (BPEL); most platform vendors are adhering to this standard. BPEL is essentially a programming language but is represented in XML.
BPEL provides:
Although the BPEL syntax is rather straightforward, a graphical representation of a business process is preferable, so you’ll benefit from a GUI design tool to assemble business processes from existing services. Thus, creating business processes is a relatively simple task if you understand your business processes and you’ve deployed services available for your use. The Oracle BPEL Designer, which can be used as either as an Eclipse or JDeveloper plug-in, helps you design business processes, making it easier to design and develop services.
In addition, you’ll need a high-performance processing environment (or server) to execute he generated business processes, and a management tool to test and monitor the status of these deployed processes. Most SOA platform vendors such as Oracle and IBM now have a robust platform to deploy business processes. For example, Oracle provides the Oracle BPEL Process Manager to deploy and execute business processes and Oracle BPEL Console to test and monitor business processes.
Presentation Layer: The Data Binding Problem
The presentation layer is very important from a user perspective. This layer can be built with technologies such as JSP, JSF, portlets, or standalone Java clients. For developers, it’s an uphill battle to achieve loose coupling between the presentation layer and the business logic or service layers. Several Model-View-Controller (MVC) frameworks, which have been in use for a long time, allow for loose coupling between the view, or presentation layer, and the model that supplies the data and business logic. This lets you change either the view or model with minimal impact. This does help us achieve the type of loose coupling we want between the presentation and service layers. The main problem, however, is that there’s no standard way of binding data between different kinds of clients (such as JSP, Java clients, and services such as EJB or web services), and clients have to know the exact underlying implementation of the service layer.
Best Practices
Here are a few best practices to follow when building service-oriented applications:
1. Do not jump into implementation technologies just because of the hype. Carefully consider whether web services make sense for your organization. Building a service-oriented application using traditional technologies such as RMI may be more appropriate for your use cases than using web services.
2. Modularity of services is very important. Do not build fine-grained services, as this will result in a tightly coupled, brittle infrastructure.
3. For most applications, interoperability is important. Adhere to the WS-I best practices–and even then, make sure to test for interoperability with your preferred clients.
4. If it doesn’t make sense to use web services for your application, there are alternatives. Many BPEL process managers, such as Oracle BPEL Process Manager, let you use native protocols.
You must be logged in to post a comment.
