Message flow
How to model the message flow? The best answer to this question is it must be as simple as possible. Why? Consider that the OSB is the center of the communication. If we just consider the performance of the network then the OSB seems to be unnecessary as this is just a new station between two systems. It may slow down the communication (Ok we know the OSB is a very important IT platform of the company).
The message flow must be quick and contains the least steps. Of course we have to be concerned with some basic things as error handling and monitoring. But we have to put these logics into the message flow not to disturb the main workflow (e.g. At the beginning of each proxy services we have to call a monitoring system. To consider the conclusion above we have to make an asynchronous call to monitor system not a synchronous one).
It is very important to understand that the OSB is not a business workflow engine. You mustn't implement this kind of logic in the message flow. And the next question is evident: What should we consider the business logic? The answer is difficult. You have to think of the OSB as a funnel. You (the client) fill something (e.g. milk) on the one side and You (the server system) get the same (milk) or other (chocolate milk) thing. But You don't do anything just fill! Ok, I think it is enough of the metaphors... :)
Usually the proxy services use just one source system (business service). The OSB service can modify the requests / responses, change the protocol, add some basic functionalities and so on. If You should use more source systems in the proxy service You have to consider to implement it in a workflow engine. If You haven’t got such an engine You can develop enterprise services in the OSB.
To decide what You may put into the OSB depends on your actual IT possibilities as well. If You have got a BPEL engine then You can take out easily the logic which is complicated to implement in the OSB. But if your the company has got just the OSB (and not BPEL engine)... well in this case we can't put this workflow into a non-existent workflow engine. It is sad to say but You don't have any other chance just to implement these logics into the OSB (if the tools of the OSB are sufficient for this...).
The OSB enterprise service use more systems not just one. They are built on the existing services of the company systems but they seem to be new ones. You have to find out the requests/responses, the message flows and how to transform or summarize the results of the called systems. So these ones are the so called enterprise services which are brand new services in the IT platform of the company.
Every message flow is different but there are similar / general parts. We have to find these high level parts to develop the message flow easier. Check the next figure:
Monitoring
So the first step is the monitoring. I illustrated this with dotted line which means that I don't think this step is compulsory in each cases. This step is necessary in those cases if the proxy service is an asynchronous service. For example if You receives an email and an error occurs then usually it is not reasonable or there is not any chance to send back an email about the error to the sender. Or in case of FTP we should send back a file...?
But it is rarely informative to monitor if a synchronous service is called. The monitoring funcionality is belong to the client in this case not to the OSB. But if we consider an asynchronous service this is the task of the OSB. You should monitor as much information as possible (of course it depends on the possibilities of the monitoring system as well).
Check the incoming data
It is very very essential to check the incoming data before using them (e.g. to send to source system). Here there is a good chance to use the OSB: we can disencumber the source system. It is absolutely unnecessary to call the source system if there is no chance for a successful execution. Usually we have got two tasks to do in this step:
- to validate the data
We know the expected structure of the data so the validation of the incoming data can be performed. We have an easy task in case of webservice (the structure is determined in the WSDL) but in the case of other protocols the structure is discovered in the phase of business design already. Usually we use scheme to validate but other validation logic can work as well (e.g. in case of text files). - to check if any necessary information is available
We have to examine if we have got all the data to call the source system. For example: if we develop a service to send an email and we doesn't receive the email address then we have to raise an error to the client. Of course we can handle these cases with the XSD as well but there might be situations when we have to check this without the help of the XSD (e.g. the XSD mustn't be modified).
After we checked the incoming data sometimes we have to transform it. What I mean to transform? Just remember, an important usage of the OSB is to play a gateway role between systems. For example if the CRM system wants to communicate to the billing system and they have got different data structure then it should mean some development works in one of the systems. But it doesn't because You can make the conversion in the OSB! The costs might be lower as if You should start a development project in a legacy system...
When I am talking about conversion I mean XQuery transformation which is a powerful tool to transform an XML to an other one. If the source is not an XML then You have to develop individual solutions. If You should change the namespace of tha XML only then You could use the action 'Rename'.
Create the request for calling the source system
To call a system we need a request message. How to create the request depends on the protocol (I won't specify all of them but the more important ones for me):
- Webservice
We have to create a SOAP message. We have to set the body part of the message and occasionally the SOAP header. Usually we use the header to set the security (e.g. OASIS security or custom solutions).
We have already produced the data to send before this step so we just have to put it into the SOAP body. Sometimes we have to add some tags to the XML. To be clear have a look at the next sample request for the header part:
<soap-env:Header xmlns:ws="http://ws.billing.acme.com/"> <ws:username>...</ws:username> <ws:password>...</ws:password> </soap-env:Header>and for the body part:
<ws:receiveOrder xmlns:ws="http://ws.billing.acme.com/">
<ws:Container>
{$incomingTransformedData}
</ws:Container>
</ws:receiveOrder>At the first sample we use custom security solution, we put the user and password into the SOAP header. At the second sample we have produced the variable 'incomingTransformedData' already in the previous step so we create the SOAP body and put this data into it. To send an email you have to use the action 'Transport Header'. You can set the email address of the sender and receiver and the subject (and a lot of other things as well...). The content of the email has to be put into the internal variable 'body' when you use the action 'Routing' or 'Service Callout'. It can be any text or XML but it depends on the mail system.
If you want to send attachment as well then you have to insert a similar XML to the internal variable 'attachments':
<con:attachment xmlns:con="http://www.bea.com/wli/sb/context">
<con:Content-Type>application/octet-stream</con:Content-Type>
<con:Content-Disposition>attachment; filename="{$fileName}"</con:Content-Disposition>
<con:Content-Transfer-Encoding>base64</con:Content-Transfer-Encoding>
<con:body>{$fileContent}</con:body>
</con:attachment>- FTPYou have to use the action 'Transport Header' in this case as well. The name of the file which will be sent through FTP can be set in the property 'fileName'. You can set the FTP endpoint dynamically with the action 'Routing Options'. And again you have to put the content of file into the internal variable 'body'.
- any Java serviceYou can call a service of a Java service (e.g. session bean) directly from the OSB. The key is the action 'Java Callout'. If you have got the client (proxy) java classes of the session bean in a JAR file and put to the classpath of the OSB then You can use them in the action 'Java Callout'. This is a simple but not too elegant possibility to use a Java service in the OSB.
You can reach an EJB3.0 service directly from the OSB but this is true only the EJB3.0 services.
Call the source system
To call a system you have got two possibilities: routing or service callout / publish. If you need to execute some steps after calling the system then You have to use service callout / publish (first one is for sync. services, second one for async. ones).
You have to pay attention for the error handling. To thow the exception to the client or catch them? I will deal these questions later in another blog.
You have to be concerned with the parameters (e.g. retry interval, retry count) of the calling. If you don't set the values of these parameters prudently then it can cause an unnecessary bottleneck. The attibute 'Retry Application Errors' of the business services is such a parameter as well (why try again if the source system sent back a response?).
Transform the response of the source system
This step is similar to step 'Transform the incoming data'. This step is unnecessary if the proxy service is an asynchronous service or there is no need to transform the data.
Create and send back the reponse
If our proxy service is synchronous then we have to send back a resposne to the client. If the source system synchronous as well then we send back its response to the client. If it is asynchronous then we have to create a reponse to send back. Usually these reponse are not complicated just a sign that the execution of the operation was correct.
