Today, we are living in a world, where 'the age of information technology' is erasing the boundaries of cities, states, and countries. This age is all about M and A's and key to the success of such partnerships would depend on how well current independent resources of each of these entities is re-used. But the biggest challenge would be aligning these independent solutions into components that can be re-used across the enterprise.
The answer lies in "architecting" a design that would take care of inter-enterprise communication in a scalable form. But before getting into that, let's first try to understand the term 'architecture' in the broader sense. This is one of the most under-valued but the most important building block for any solution.
"Architecture" is a Holy Grail for any design solution. It shows the major components of the software solution and serves as a blueprint for the entire design. It is like a core to the design of complex software solution.
It can be defined as a representation group(s) of relationship between various components of a complex software solution. The solution is decomposed into smaller, self-describing components and represented as structural relationships to provide a high-level overview of the entire system. The system is divided into runtime elements, which in itself could have architecture as well.
Shown here is a typical architecture for a database driven, web-based solution. It provides us with a high-level overview of the entire system. The consumer only has a view of the 'presentation layer' and other layers are tightly encapsulated. Each layer would have its own characteristics as well as its own architecture.
Architecture can be compounded as a logical set of decisions to describe the life of the project. These decisions will have a cascading affect on the selection and integration of components such as the selection of software, hardware, and behavior of the system. A good architecture will also take care of the future needs of the project.
But then, why is architecture so important? Without proper architecture in place, it would be difficult to achieve the following:
Achieve our designed goal
Decompose our requirements into smaller entities
Quality solutions
Change management
Re-usable or extendable solutions
Achieve business goals
Moving on from architecture, we will now dive into different architecture paradigms.
"Architecture" is a Holy Grail for any design solution. It shows the major components of the software solution and serves as a blueprint for the entire design. It is like a core to the design of complex software solution.
It can be defined as a representation group(s) of relationship between various components of a complex software solution. The solution is decomposed into smaller, self-describing components and represented as structural relationships to provide a high-level overview of the entire system. The system is divided into runtime elements, which in itself could have architecture as well.
Shown here is a typical architecture for a database driven, web-based solution. It provides us with a high-level overview of the entire system. The consumer only has a view of the 'presentation layer' and other layers are tightly encapsulated. Each layer would have its own characteristics as well as its own architecture.
Architecture can be compounded as a logical set of decisions to describe the life of the project. These decisions will have a cascading affect on the selection and integration of components such as the selection of software, hardware, and behavior of the system. A good architecture will also take care of the future needs of the project.
But then, why is architecture so important? Without proper architecture in place, it would be difficult to achieve the following:
Achieve our designed goal
Decompose our requirements into smaller entities
Quality solutions
Change management
Re-usable or extendable solutions
Achieve business goals
Moving on from architecture, we will now dive into different architecture paradigms.
At the most granular level in a system, you will always find sets of applications running to achieve some business goals. These applications are developed using different kinds of blueprints that we refer to as architecture. They provide an abstract view of the entire application, or let us say a high-level overview of the system.
Application architecture can be considered as a representation of the structure of components and the interaction between them in the system. They provide a framework within which the business objectives are represented.
The previous figure shows a typical architecture of a web-based application. The business requirements are converted into a high-level design where the:
First layer of 'HTML or JSP' acts as the presentation layer.
The business logic is encapsulated in the middle layer that could be built on Servlets or EJB.
Finally, the data is handled in the third layer 'MySQL'
Each organization will have multiple application architectures, which would cater to the need of different business goals. These applications could be web based, or even the custom client server applications.
The client-server architecture also known as two-tier architecture separates the client from the server. Client is the system requesting a service from the provider (in our case, server). The client will always initiate the request, which the server processes and responds to. The client could send the request to one or more than one server at a time.
Using this architecture, you can divide the responsibilities of the requester from the provider. Earlier, as seen in monolithic systems, objectives were divided into smaller pieces, and then tightly coupled into an application. Due to this, it was difficult to process multiple clients. But, with the client-server architecture in place, business process is done within the provider. This enables multiple clients to be plugged in at the same time.
Large organizations usually have more than one application to support their business goals. These are well supported by mainframes. Mainframes act as the core business-processing unit with capacity to handle large chunks of data transactions. Other computers in the organizations access the mainframe to achieve the business goals. So in a way, the mainframes act as a server, and cater to different clients across the organization. With the advent of monolithic computing, where applications were tied to the data sources, the client-server architecture had become a welcome sign for the industry.
The main advantage of the client-server architecture is that it is scalable. With minimal performance impact, either the client or the server could be added.
Client-server architecture can be divided further into 1, 2, 3....n-tier architecture. We will glance through each of these. The architecture is made up of three basic layers — the presentation layer, the business layer, and the database or services layer.
Presentation layer is the one with which the client will interact. The consumer shall either move through a click-based solution, or will input data into the front-end to initiate the business process.
This layer could either be a thin or a fat client.
Business layer will enumerate the consumer action(s) and process the information supplied by the 'presentation layer' to accomplish a business goal with a set of business rules.
Data layer stores the data and logic that would be used to successfully achieve business goals.
The single tier application would have the three layers, that is, the presentation, the business, and the data layer tightly coupled which runs out of a single processing unit. The application is designed in a way that the interaction between the layers is interwoven.
Within the tenets of client-server architecture, the single tier application can share the data layer in a multi-user environment and achieve the client-server capabilities. The limitations of 1-tier application in client-server architecture are as follows:
Changes to the database, in case it is being edited by multiple users
Difficulty in scalability, as the application is running on a single machine.
Within the 2-tier application, the presentation and the business layer combine on the client side, while the data layer acts as the server. This enables the business logic to be separated from the data services.
The 2-tier application would generally consist of a 'fat' client and a 'thin' server - 'fat' client because it will embed the presentation as well as the business logic of the application, and a 'thin' server, as it will only cater to the data needs of the client.
Another flavor of the 2-tier application can be a 'thin' client and a 'fat' server. This would have the presentation logic served in the 'client'. The business logic and data logic reside on the 'server'.
As the business logic was independent of the presentation logic, it enabled different forms of GUI to connect to a particular business process. The GUI would be served as a simple HTML application, or it could be any form of complex presentation logic.
Within a 3-tier application, the business layer would reside between the presentation layer and the data layer. This enables the presentation logic to be independent of the data layer, and all its communication will happen through the business layer only.
The business layer is usually multi-threaded so that multiple clients can access the business process. Typically, these business processes take up client calls, convert them to database queries, and then call the data layer. Subsequently, it will translate the response from the data layer and pass it to the presentation layer.
The critical advantages of the 3-tier application are:
The business layer can be multithreaded, which enables multiple clients to access the business functions.
Enables the presentation layer to be light weight, as it does not have to take care of the database queries.
The components in each layer are re-usable.
Each of the layers is easily scalable. Thus, it enables load balancing and clustering.
An n-tier application will usually have more layers than the 3-tier application. Typically, the business logic from the middle layer would get structured in two different layers. Some part of the business logic will reside in the application server that connects to the data layer and the other part of the business logic shall remain in a web server, which will connect to the presentation layer.
In a typical web-based solution, the client will have access to the business through a browser. The browser in turn will call the business logic in the web-server. The web server will subsequently transfer the calls to the application server, which effectively sends the request to the data layer.
Advantages of having n-tier application:
Initially, solutions were designed to achieve certain set of goals only within the organization. Those solutions were usually built on the principles of local client-server architecture, that is, 2-tier or 3-tier architecture. But for large organizations with growing businesses that spanned across geographical locations, the localized solutions started to get redundant. A need was felt to design solutions that could interact with each other, independent of any geographical boundaries. These solutions had to be multi-tiered. In this context, we have to talk about the term 'enterprise computing'.
A large organization — with several functional entities such as HRD, Sales, Marketing, IT, and Finance — is known as 'enterprise' in the computer industry parlance. Each of these entities have their own set of business goals to achieve through different software solutions.
'Enterprise Computing' design makes it possible for these functional units to run on shared environment and infrastructure. It enables each of the units to share common data within the organization as well as with its trading partner.
The architecture used to design solution based on enterprise computing is 'enterprise architecture'. This architecture helps organizations achieve business goals. At a higher level, enterprise architecture can be divided into four layers:
The first step to evolve good enterprise architecture is to model the business processes that are directly dependent upon the business strategy.
Business logic can be set up as follows:
1. Capture business requirements
2. Analyze requirements
3. Define business strategy around the requirements
4. Model the process
The business requirement are captured and documented. The next step would be to involve different business line managers, analyze the requirements, and then define business strategies to achieve the goals as stated in the requirement document. Finally, the business process model is designed to give an overall view of the entire business process. It can be achieved through various business process model (BPM) tools.
Let's take a contextual example of a local super store. The store caters to the consumers through different business lines such as retail, procurement, HR, and IT. Each of these service lines is inter-dependant. To retail a product, the procurement has to be done. To procure a product, it has to be ordered, and to order a product people are needed. The business process has to be designed considering all these entities.
Application will be needed in the organization to supply information to the business. Application serves as a bridge between data and the business processes. To support business goals, processes retrieve information through proprietary applications.
The applications are developed using their own reference architecture. This architecture provides a view of the processes that would be defined during the application development. These processes have a clear demarcation of their activities. For example, the process to retrieve the data would be different from the process to push the data to business.
Continuing from the super-store example we stated earlier, each of the business lines within the store will have its own applications. These applications will in turn communicate between themselves as well as use the information to achieve their individual business goals. For instance, if a product has reached the re-order level, business process are built to re-order the product. This process will use the application to check the current quantity and the re-order. In case the product is sold, it will reduce the quantity.
Just as a fish cannot live without water, an enterprise solution cannot exist without information. Information is the critical building block to any enterprise solution. It constitutes a major part of the solution, which the enterprise architect has to take into consideration:
Data redundancy
Data re-use
Access control
Regular backups
These checks help in maintaining the accuracy of data for business processes.
The success of any enterprise solution will depend upon the appropriate technical decisions. Implementation of applications and the use of information will depend upon the type of technical components being utilized.
The choice of hardware and software components will depend upon the current infrastructure assets, and the correct alignment of the components in the business processes. Traditional 3GL languages are still used in bigger enterprises where performance is as critical as the business. But the new world prefers to use the 4GL languages.
The enterprise systems are designed in a way that all the business goals can be shared by all the consumers, and at the same time it does remain abstract. The sharing of info could be done with various supporting interfaces. For example, where data needs to be exchanged, it can be done through XML interfaces. These data can also be referenced through HTML or other UI systems.
Moving to 'enterprise computing' designs, the organization started to reap good profits. Let's list the advantages of 'enterprise computing':
It enables the concept of 'paperless' office, as all communication can be routed over the internet, thus removing the dependence on standard mail, fax, or even email.
Man-hours, consumed to do the menial tasks, are reduced.
The collaborative mechanism approach enables better and faster supply-chain management
The turnaround time for moving the product from the manufacturing hub to the store is vastly reduced.
Data between each of the units can be exchanged faster, greatly reducing the cost-to-carry.
Now, when we talk about data exchange, the major hiccup comes in the form of security. The sensitive data exchange has to be accomplished in a secure environment, as the networks are open to intruders most of the times. This could cause immeasurable losses to the enterprises. Security can be achieved through various means such as using secured HTTP protocols, authentication, and proper logging mechanism. It can help to catch leaks and send appropriate notifications, access controls, or enable only a set of users to access the resources.
Further, with the growth in size of enterprise solutions, the need for administration became very important. As the enterprise grew, so did the number of software and hardware components. Any errors or inherent bug in the solution need careful debugging and resolution process.
Many times, the software components would require an upgrade, which spanned across the multitudes of business lines. So, application administration was required to ease the task of upgrades and timely resolution of errors.
The managers have a fair idea of the business process and the need for improvement in various solutions. They are the people who run the business and are single-handedly responsible for the continuous improvement of the system. These improvement needs are guided by the goal to achieve continuous high quality growth in each of the business systems.
To achieve it, managers always need to have an overview of the enterprise system, which can be achieved by involving the managers during the design of the solutions. The managers can get involved in the design with their inputs on the business goals, and help to set up business rules to achieve these goals. These would be helpful in case a system needed improvements, or while debugging any inherent issues.
Managers who are aware of the enterprise architecture give a greater fillip to the organizations to achieve better quality and consistent growth, as they can relate the architecture to the business goals better, using the data gained out of the system. They can design various metrics out of the data to analyze the growth and address any impediments in achieving their targets.
For developers, architecture is a ready resource to the way they understand the business requirements. Successful enterprise solutions are a derivative of good enterprise architecture. Depending on this understanding of the architecture, decisions are made by the developers on:
Development milestones
Development strategies
Choice of proprietary software solution
Choice of hardware
Choice of manpower (for the technical leads)
A perfect blend of the above will result in the successful implementation of enterprise solution vis-Ã -vis the enterprise goals.
But, EA solutions had its share of challenges. We will try to discuss some of the common challenges faced by the organizations that were dependent on enterprise architecture techniques to accomplish their business goals:
1. Proprietary Solutions: With the organization's business horizon growing, it had to incorporate EA solutions that were traditionally being delivered through proprietary software, or there was a wide use of proprietary software either on the side of the organization, or its vendors. This led to many more challenges in the dissemination of data between the concerned parties, which ended up impacting the business goals and delivery timelines.
2. Point-to-Point Integration: EA solutions required applications within the organization to communicate with vendor application for the exchange of data without any human intervention. This required business process to make a one-to-one connection with the vendor-side process.
Problems with Point-to-Point integration:
For large organizations, an increase in number of point-to-point interface leads to chaotic maintenance issues.
It becomes difficult to re-use organizational business processes as they are tightly coupled with vendor process.
It requires dedicated hardware connections to the vendor.
The ROI declines over the long term, because when each client is added, the hardware and software connections have to be made. This increases the infrastructure costs in the long term, as the number of vendors increase.
Only one-way communication is possiLet's begin by analyzing and designingble including messaging. Suppose the message sent by Vendor process has to be propagated to the other vendor system, in this case a new solution will have to be set up and maintained.
3. Technology: New technologies are arriving at a fast pace, and all of them want to market themselves as the best solution providers. But this is the place where organizations are thrown a lot of challenges. Although the new technology will reduce the time to implement the business processes, organizations have to estimate how it could affect the current processes. They have to choose between upgradating and investment in the current systems, or maintenance of the existing systems.
The cascading effect is seen in business processes that interact with trading partners. With the change in technology of the business processes on either side, the information flow and connections have to be reset. This will need investment in the form of man-hours and, in some cases, additional hardware resources.
4. Standards: Business processes being tightly coupled to the vendor processes, information exchange follows a set of agreed standards between the two. This leads to less openness and re-use of information. The challenge is to convert the organization's meaning of a data item to various vendors' data item. A shipping order should not be conceived differently between the two vendors. A common standard for information exchange has to be set up, which would translate the meaning across vendors.
5. Mergers and Acquisitions: With rapid globalization, many organizations are looking for opportunities to expand their businesses. So mergers and acquisitions have become the order of the day. But for IT, these have become one of the major challenges. There is a high need for either revamping the current processes, or setting up additional infrastructure to develop new offerings. There is a constant lack of cohesiveness between the business processes, and the advantage of shared growth is lost. This loss can be seen in multiple solutions for the same set of business processes such as in a shipping order or a simple login mechanism.
This can have an effect on the business of the organizations. In the long term, strategies have to be realigned to take advantage of the fast-paced growth. Open standards have to be set by organizations, so that information can be exchanged more easily. These will help in tiding over the current set of challenges offered by EA. Organizations need newer strategies for:
Faster time to market
Meeting information exchange challenges
Loose coupling between the business processes
Re-use of infrastructure
For organizations that are truly bent on developing new strategies to achieve their renewed set of goals, here comes SOA to their rescue.
"We are building business processes around web services in our solution. So, we're essentially developing a SOA-based solution". Well, this is the common perception across the ranks within the organization, and at times even the architect would say it. But is that really so?
Well, in our opinion, that's not true. Just because you are using web services, it would be unfair to classify it as a SOA-based solution. So, what exactly constitutes SOA? This has become a focal point in the various discussions that we're involved in during our day-to-day life. Defining SOA is a challenge in itself. In a nutshell, we need to understand that SOA is an architectural concept. To understand our point of view on SOA, let us first go through web services and the 'orientation' of web services.
With the aim of re-using the business processing logic, and moving away from point-to-point communication, a need was felt by organizations to promote information across vendors. They were required to communicate over the web, using a set of standards. So, processes were set up to be accessed over the web to execute the business logic.
The communication was independent of the underlying technologies on either side. Use of web services eliminates the issues of application servers, operating systems, protocols, or devices. Regardless of the above, vendors can call the web service to accomplish a set of tasks.
We have been hearing about object-orientation for a long time. Extending the concepts further, we try to explain the 'orientation' of web services. In a nutshell, it is an enterprise solution with a plethora of business processes exposed as web service. But each of this process has to be defined according to the business goals they are supposed to achieve. Orientation is the process of mapping the business processes, and enabling them to conform to the business goals.
The web services expose the business process and communicate with the Application logic to accomplish a business task. These web services can be accessed within and outside the organization.
We will go into the details of each of these in the'Why SOA?' section.
SOA is not a solution, it is a practice.
The term SOA was first coined by Gartner analyst Yefim V. Natis in one of the research papers in 1994. According to Yefim:
SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations, and interface calls...
Despite being coined much earlier, SOA started to become a buzzword only in early 2000. With the advent of web services and WSDL compliant business process, SOA started to become popular among technology enthusiasts.
The fundamental of SOA is based upon:
Service
Message
Dynamic discovery
Web service
The fundamental approach of designing web services that offered the business logic to be decomposed amongst disparate services, each of which was a distinct logical unit but in entirety was part of a distributed enterprise solution. These logical units are services.
The business logic gets encapsulated in a service. As seen earlier, a service can be an independent logical unit or it can contain in itself other set of services, as shown in figure 1. In case the service is used to call other sets of dependant services, to refer to those services, they must contain the service descriptions. The service description in its basic form contains the information of service name and location of the service being called.
These logical units though had to adhere to certain sets of communication standards to enable information flow across the enterprise offerings in an understandable form. The information is exchanged in the form of messages from the interface designed within the system. The interface exposed by a service contains the service behavior and messaging pattern. One of the basis of SOA being platform-neutral is that messages are exchanged in XML formats so as to adhere to the concept.
At a high level, SOA is formed out of three core components:
From the preceding figure, we can see that:
The service provider offers business processes in the form of services.
The services offered by the provider are called by the consumer to achieve certain sets of business goals.
The process of services being provided and consumed is achieved by using directory services that lie between the provider and the consumer, in the form of broker.
The service to be made available to the consumer is published to the directory services in the broker. The consumer wanting to achieve the set of business goal(s) will discover the service from the broker. If the service is found, it will bind to the service and execute the processing logic.
This helps in achieving the objective of using SOA:
Loose coupling: The business process being decomposed into independent services will help in bringing down the dependencies on a single process. This in turn will help in faster processing time.
Platform-neutrality: XML-based message information flow enhances the capability to achieve platform neutrality. These XML messages are based on agreed XML schema, eliminating the need to set up other messaging standards that can differ across platforms.
Standards: The message flow across the enterprise is in the form of globally accepted standards. The service only has to depend on the service descriptions without worrying about the target standards and removing the dependencies.
Reusability: The business logic being divided into smaller logical units, the services can easily be re-used. These enhance the utilization of SOA-based solution, which has a cascading affect on service delivery and execution.
Scalability: Again, as the business processes are decomposed into smaller units, adding new business logic is easy to accomplish. The new logic could either be added as an extended unit of the current service, or it can also be constructed as a new service.
We have discussed above the concepts of SOA and the components that constitute the design of architecture based on service orientation. In this section, we'll try to determine the need for organizations to align their business process, and design it according to service-oriented concepts, joining the SOA wagon wheel.
Integration: An SOA-based solution is usually based upon the principles of inter-operability. The integration solutions thus offered are loosely coupled and less complex. At the granular level, services are being used to interact with vendors. The compounded benefit can be found in the lower cost of integration development, as we move away from proprietary integrations solutions to open standard-based solutions.
The ROI can be easily measured for integration solutions as the cost per integration is drastically reduced by the use of SOA-based solution against the traditional middleware solutions. Over the period of time, organizations can move away from the current, expensive, integration solutions to SOA-based vendor-neutral integration standards. It can be achieved by standardizing the current service description and messaging solutions.
Business Agility: One of the most important benefits of organizations adopting SOA is felt by the increased agility within the systems. Though agility is a non-quantifiable term, the inherent benefit is felt within the organization's hardware and software assets.
The benefit in terms of software assets can be derived from SOA's ability to re-use and simplify integrations. Unlike earlier days, where development of new business process would take quite some time, the current business users will find the development period getting shortened. This makes it easy to accommodate changes, and the benefits of the same can be seen in the long term, as the enterprise solution evolves over a period of time.
In terms of hardware benefits, due to the abstract use of services being loosely coupled, they can be delegated across the domain and the results can still be achieved. This helps in balancing the business processes load across the organization, and the capabilities can be utilized better. Thus, a remarkable improvement in the efficiency of business can be felt.
Assets Re-use: The foremost goal of a SOA-based solution is 're-use'. Most of the earlier solutions were built-in a very tightly coupled or an isolated environment. This made it very difficult to re-use the components of the current solution.
SOA-based services were built in such a manner that, though the services conformed to the current business requirement, they could still be re-used in any composite service. As a result, organizations saw the benefits of re-use in terms of a higher intial development period. But over time, the economics of re-use got better of the development span. The economics of re-use was felt in terms of faster integration and lower cost per integrations. Re-use also enabled organization to put less money into asset growth, as the current assets were being re-used effectively.
Increased ROI: With proper governance and compliance in place, and a highly secured transaction environment, the adoption of SOA sees a definite increase in terms of ROI.
With the integration solutions moving from expensive, tightly coupled, standard-specific, vendor dependent to being loosely coupled, vendor-neutral, open standard-based solutions, the cascading effect on ROI is seen immediately. Over time, as organizations move away from proprietary solutions to SOA-based solutions, the investment in integration assets will surely dwindle.
Building solutions that are inherently re-usable helps organizations to build and market the solutions in a rapid manner. This helps organizations to improve their time-to-market, and improve efficiency with respect to customer satisfaction, service, and effective use of manpower.
As a lot of organizations move towards adopting the SOA culture, the biggest issue faced by them is the complexity of the solutions. The dismantling of the current business processes into smaller services is a huge challenge in itself. SOA is a natural improvement over the object-oriented (OO) and the component-based development (CBD). So, it still retains some of the flavors from each of them.
The business processes are powered by small pieces of software known as 'components'. The business logic inside the components is based on the principles of OO programming. These business processes are termed as 'services' in the analogy of SOA.
The recipe for success of any SOA solution is to ensure the classification of business processes into smaller units. You can either choose the top-down, the bottom-up, or the middle-out approach.
Top-down: In a top-down approach, the business use cases are created, which gives the specifications for the creation of services. This would ensure that the functional units are decomposed into smaller processes and then developed.
Bottom-up: Using the bottom-up approach, the current systems within the organization are studied, and suitable business processes are identified for conversion to services.
Middle-out: The middle-out approach acts as a spy, and tries to locate suitable business processes that were left out by the other two approaches.
From the above discussions, we can identify that 'services' are the core components for the success of a SOA-based solution. We will try to explain the term in the following discussion.
'Service' as a sole unit is an independent logical unit of a business process. The business logic stands encapsulated into the service, and it interacts with the outer world through the 'interface'. The services are designed to be flexible in terms of addition of new business logic or change of logic. They should also be reusable, so that other processes can use functionality. Services are published by the 'provider' and they bind to the 'consumer' through the service 'handler'.
The Service provider: The provider comes into action when the service is invoked. Once the service is invoked, the provider will execute the business logic. Messaging will depend upon the business logic, in case the consumer expects a message after the execution of business process, the provider will send out the reply.
The Service Consumer: The consumer would send out a message to the provider in order to access the service. This is the requester. It would either be done directly by a service-to-service call or through the directory services. Services required for processing are identified by their service descriptions.
The same service can act as the provider as well as the requester of the service. But this is seldom seen in practice. Here, we have extended the above image further:
The Service Handler: The service handler acts as a collaboration agent between the provider and the consumer. The handler contains the realization logic, which will search the appropriate service provided and bind it to the consumer request.
Once the service has been requested, it goes through various messaging paths and, at times, into multiple handlers to finally accomplish the logic. The handler usually routes the messages to the target system or sometimes does some processing logic before forwarding the request to target system.
WSDL — Service Description: Service Description carries information about the service such as the input or output parameter, the location of the service, port type, binding information, and so on.
This helps in locating the service when a consumer requests for the same. This information is stored in the form of a WSDL (Web Service Definition Language) document. In a nutshell, the WSDL document will have all the information needed by the consumer to locate and execute the business logic within the web service.
The WSDL can be classified in two different entities: abstract and concrete. The abstract definition constitutes port and messages, whereas the concrete definition will constitute the binding, port, and service information.
The messages are structured within the XSD (XML Schema Definition) and processing rules are defined as part of policy within the WSDL.
Messaging in the SOA paradigm is one of the most important blocks. The inter-service and inter-vendor sharing of information is done through messages. SOA-based solutions have an exhaustive usage of messages. The messages are designed in an agreed upon standard format to be used by services across the SOA-based solution.
SOAP is the standard messaging protocol agreed upon by the industry as a means of sharing information over networks. The information is stored in the form of XML data within SOAP.
SOAP specification consists of:
Envelope
Header
Body
Each SOAP message will consist of an envelope, header, and a body. The header will contain information about the SOAP message and all the metadata required by the message. This is, however, an optional element in the SOAP envelope.
The body contains the actual message required for execution of the web service at the endpoints. The message conforms to the XML standards. The body also includes information about faults — a way of error handling. A message can be added in case an error occurs while processing. This field is also optional.
As part of the messaging framework, enterprise solution uses nodes for SOAP messages to communicate across the platform.
SOAP nodes are supposed to perform the processing logic on receiving a SOAP message. The node is identified by an URI.
The nodes can be:
The SOAP intermediary
The sender of the SOAP message
The initiator of SOAP message
One of the most common messaging styles is the RPC (Remote Procedure Call) mechanism. It enables developers to make a call to the remote services over the HTTP.
For making RPC call, the payload within the envelope will represent the method call. In the conventional way, the method name will be used for request and the responses come in the form of "Response" being appended to the name for example, PurchRequest or PurchRequestResponse.
It is the path taken by the message from the moment it was initiated by the request till it reaches the target service.
The path starts from the service requester and moves towards the logical end of the service. Message Path is important, as it will determine the flow of service and address the concern of security, data management, and service management.
Many times, the message path is not pre-determined, and would depend upon the number of intermediaries between the requester and the target.
More on WSDL and messaging style will be covered in the next chapter. This way, we have addressed some of the tenets of working up on SOA.
In this chapter, we have covered:
1. Role of Architecture: This describes the importance of designing a sound architecture for successful implementation of any business solution.
2. Client-Server Architecture: Different type of client-server architecture has been offered for reference. They serve as prologue to the service-based architecture.
3. SOA: We have tried to cover the various tenets of SOA, explaining the fundamentals and explaining the advantage of using the service-oriented architecture in designing a business solution.