IBM’s definition of SOA says “Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services”.
It is important to note that SOA is not a product but is an architectural style.
An example of enterprise systems is an Enterprise Resource Planning (ERP) system used in many large organizations.
The main features an Enterprise Systems must have are:
Availability – If the system cannot handle the load, it will result in a system downtime and can impact the company’s business performance.
Scalability – The systems need to have the scalability feature in order to adopt the new changes happening in the organizations
Performance – shareholders and managers care very much about the performance of enterprise systems used in their organizations.
Security -The systems have to be secured in order to ensure the continued system availability and data confidentiality.
Manageability – the Enterprise Systems Management (ESM) specialists have to monitor the system operations as well as the performance in order to track down the source of problems and then pinpoint and fix the problems in the underlying layers.
Data Integrity – Data integrity means that data in the systems should not be lost or corrupted.
Interoperability – enterprise systems are required to be interoperable so that they can collaborate with other systems.
Prolem which SOA solves:
Isolating business logic – Business logic simply refers to business rules that are most likely imposed by non-IT folks within the organizations . Programmers when building the software, not only they have to have to incorporate these business rules they also have to be concerned about “computer logic”, things like “checking if the database connection is available”.
The biggest problem in programming is often it is very difficult to keep the business logic separated from the so-called “computer logic” as mentioned above. What makes matter worse is that these non-IT folks can change the business logic any time, without understanding how a small change could result in possibly disproportionate amount of work required by the IT folks to implement the change.
Interoperability – The ideal scenario is that there is homogeneity in the systems used across the organizations. Again that is simply hard or not even possible. Even if it is, in the context of the business world, the company might acquire another company that uses a totally different IT system altogether. The result is that additional work has to be done to allow interoperability. This can yet introduce another problem associated with the reluctance to migrate or upgrade existing system. Having invested effort and resources to allow interoperability, migrating to a new system might pose challenges if it is not compatible with existing system.
Software silos – The problem is that many applications and IT systems end up becoming such silos. The term usually refers to systems that cannot communicate with other related third party systems. Redundancies – A problem that is common to many large companies is that there are many similar yet slightly different applications that are used throughout the organization. Each department usually comes out with its own version of software components rather than coordinate with other departments to see if component reuse is possible.
Non-SOA architecture
SOA architecture
With SOA, the business logic is decomposed into well-defined and reusable services which will be exposed for everyone to use. Now all the application has to do is to consume them.
Now the application code is reduced greatly. Furthermore, it is no longer needs to traverse complex objects hierarchy and the developer no longer needs to understand details of domain-specific logic.
There are several types of services used in SOA systems.
• Business services
• Entity services
• Functional services
• Utility services
Business services – It has to be relevant to the business of the organization is running.
it should have as little dependencies as possible so that it can be reused easily throughout the organization. The concept of reusability in SOA refers to reusable high-level business services rather than reusable low-level components.
Entity services – An entity service usually represents business entities (e.g. Employee, Customer, Product, Invoice etc.). Such entity service usually expose CRUD (create, read, update, delete) operations.
Functional services – it is usually a technology-oriented service and not a business oriented one. Task services can be thought of as controller of composition of services and hence its reusability is usually lower.
Utility services – They might include event logging, notifications exception handling etc.
A key concept in SOA is service composition. This refers to putting together several different services to create a new service. In that sense, services in an SOA environment can be thought of as building blocks.
Web service is a realization of SOA. It is important to note that the SOA is an architectural model that is independent of any technology platform and Web Services the most popular SOA implementation.
Hypertext transfer protocol [HTTP]
By building web services on HTTP, all the computers that are able connect to the internet can become potential consumers of web services. Furthermore, by using the HTTPS protocol, web service communication can be secured.
Extensible Markup Language [XML]
As anguage used to communicate, XML was chosen as it is a platform-independent language that can be understood by different systems.
Web Services Description Language [WSDL]
In web services, WSDL is analogous to such method signatures. A WSDL document is written in XML, so any web service consumer can understand it and invoke the service. WSDL typically includes where the service is located, the functions/methods available for invocation, parameters and its data type as well as the format of the response.
<s:element name="ConversionRate"> <s:element name="FromCurrency" type="tns:Currency" /> <s:element name="ToCurrency" type="tns:Currency" /> </s:element>
The XML above shows a possible excerpt of a WSDL document which defines a ConversionRate method that requires two parameters, namely FromCurrency and ToCurrency of type Currency.
SOAP
A SOAP message again is written in XML and sent to the web service over HTTP for web service consumption. The web service consumer or client will be able to construct the correct SOAP messages solely based on the WSDL document. Similarly, the response will also be in SOAP format. An excerpt of a SOAP message is given below.
<soap:Body>
<ConversionRate xmlns="http://www.webserviceX.NET/">
<FromCurrency>USD</FromCurrency>
<ToCurrency>SGD</ToCurrency>
</ConversionRate>
</soap:Body>
SOA IMPLEMENTATION IN JAVA EE 6
There are several web services implementation in Java technology such as Axis2 and CFX from Apache, Spring Web Services, JBossWS and Glassfish Metro.
The Java EE specifications consists of two components: Java API for XML-based Web Services (JAX-WS) and Java API for RESTful Web Services (JAX-RS).
JAX-WS is designed specifically for SOAP-based web services in which data exchange is in the form of XML. Partial implementation of the stack can also be found in Java Standard Edition (Java SE) with the utilities to consume and deploy web services. Other important specifications for web services are also described below. These APIs provide necessary tools for the developers to consume and publish web services without worrying about the technologies underneath – SOAP, XML, HTTP and WSDL.
Java API for XML-based Web Services [JAX-WS] deals with all the processing required to send and receive SOAP messages either at the consumer or at the provider, It hides the complexities of the underlying protocols. It also handles generating WSDL and parsing SOAP messages at the lower level leaving consumers and providers focus more on business logic as Java classes at the higher level.
Java API for XML bindings [JAXB] This API is responsible for mapping between XML and Java objects/classes. It is closely coupled with JAX-WS though it can be used independently to handle XML.
Web Services meta-data [JSR-181]Using annotations from the JSR 181, you can annotate a Web service implementation class or a Web service interface. It enables developers to create portable Java Web Services from a simple Plain Old Java Object (POJO) class by adding annotations, and also helps in generating a Web service with a wizard or by publishing the service on to a server.
SOAP with attachments API for Java [SAAJ – JSR-67] provides a standard way to send XML documents using Java. As the name suggests, it enables us to send attachments as part of SOAP messages according to the specifications. Besides, it is an API for handling these messages at a much lower level. Typically, we can use the API to create the messages without having to deal with the underlying XML directly and also extract information from response messages even though it requires more effort from the part of the developer.
