what kind of web service to use to send XML

[Haroon Chaudhary]

Hello, I am totally new to web services, we have a high transaction system and we put all the XML format transactions on a publish queue so that the external system can use it if they want. We have a client whose system is totally based on Microsft technology they can not access our pubish queue so it has been decided the web service will be used to send transaction XML to there system. We have thought about the solution as follow
1) write Message Driven Bean to read from publish queue
2) the Message Driven bean will raed transaction XML and transform it to required format using XSLT
2) The transformed XML will be send using Soap based Web service (which will be written by external client)

I am not sure that the above is the best approach in this kind of scenario our external client has not wriiten web service yet and they are open for suggestion that what kind of web servcie should be written. I am not sure if SOAP based web service will be ideal or we should use RESTFULL (As I am not familure what pros and cons it will have).
Also Is there any way to automate the webservice integration testing / Unit testing ??

[H Paul]

Some questions out of curiosity

1. Does your JMS provider have native API that non-JMS client can use?

2. How about the nature of XML data and the communication of these XML data in terms of security defined by CIA
Confidentialiy,
Integrity,
Authentication,
Authorization

3. Can you put those XML data/files into a FTP server where the client can pull from?
or can they have a FTP server where you can push those XML data/files into?

[Haroon Chaudhary]

Apparently we do not have the native API that they can use.

At this stage I am not sure about security need further discussion with client. Its the sale transactions in the business.

It has been agreed that we will use Web servcie. I think the FTP option was discussed at some level and was rejected by client (dont know for waht reason it was rejected).

Thanks,
M H C

[H Paul]

Beauty is the eye of the beholder.

Check: RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision http://www2008.org/papers/pdf/p805-pautassoA.pdf
and especially
Table 1: Principles Comparison Summary
Table 2: Conceptual Comparison Summary
Table 3: Technology Comparison Summary

Now you and your client can decide now in terms of what, how, where, when, why based upon your specific business/technical constraint model.

[Ivan Krizsan]

Hi!
Are all transactions to be consumed by one single or multiple external systems?
Personally, I would contemplate a document-based SOAP web service - you are just going to send transactions (as far as I understand), which is a write-operation, and will not read the transactions back from the external system (since I guess you already have them stored somewhere).
One additional issue that I suggest you to pay some attention to is error handling. How are you going to handle failed sends? Are you going to limit retries? If you limit the number of retries, how do you handle transactions that have used their retry-count?
Instead of pulling messages directly from a JMS queue, I would suggest storing them in a database table. This will allow you to store additional information; for instance current retry count, message status etc.
You can also have a message status indicating a failure that need human intervention - this will make it easy to query the transactions needing human attention from the table.
Thus, an MDB could pull transactions from the JMS queue and store them in the database, a session bean triggered by a timer can periodically attempt to send pending transactions to the receiver.
These are just suggestions - use what you like and disregard the rest.
Good luck!

[H Paul]

The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth.

True/false?

Within the exploration scope:

1. Let your system become Data Provider/Data Warehouse in the sense you store all the sale data directly into DB
and provide the client a web service to be consumed.

- no intermediate QUEUE needed
- let DBA take care of the maintain/cleanup when needed. This become historical data, the client can also get them
in case they it, for example, they could not connect to your web service due to unexpected down.

WSProvider Interface {
	boolean isThereSaleForDate(Date adate)
	List<SaleData> getSaleData(Date adate)
	...etc...
}

2. Let your client be Data Consumer, use your web service that your system provided.

	if (isThereSaleForDate(2011-11-20)) {
		try {
			List<SaleData> listOfSaleData = getSaleData(2011-11-20);  // suppose it can take 1 hour - 8 hour	
		} catch (Exception ) {
			retry later since the data is still there in the Provider's Data Warehouse 
		}
}

This is the time to test the the limit of java JAX-WS feature "Client side Asynchronous Invocation - by polling or callback" to see how far it can wait. Why not?

MicroSoft has similar concept or better. I bet. Who knows like the above quote.

[Haroon Chaudhary]

Thanks for the suggestions guys, We are having a desing meeting next week and I will put all the suggestion on table . We thought about the retry and fail response to be stored in data base. And the failed transaction will go in a differnt Queue after retry count is met. And a reporting tool will allow the user to see the failed transaction and reason for failure.

The idea about data warehouse and data consumer is good. We already have all the transactions in our database and then they are also already being published to the publish queue in our system. We will consider the feasibility for this idea as well.

Cheers,