Can we have Junit Test cases for testing Proxy, Business Services in Oracle Service Bus?
If yes can someone give me some pointers to the same.
this can be done by creating test suites to put and get messages from the queue and having your proxy do the transformation. The transformed output can then be compared with the expected out by simple string comparison.
JUnits can also be written for any type of proxy not only queue based proxies.
If your Testing technology has the ability to test Web Services or RESTful Services, then it can be applied to OSB Services.
Remember what Interface you define for the OSB Service is how you invoke it.
So if it is a REST-based interface then you will make REST Calls, if it has a SOAP-Based interface then you will Make SOAP Calls i.e. SOAP Request Messages.
In terms of Assertions, same applies just like Web and REST Service:
Response Status Code
Response Message Body (usually XML for SOAP and JSON for REST)
Related
I'm trying to do few quick prototypes of using RabbitMQ as message broker for internal services as well as messages from external clients received by gateway over websocket connection.
I decided it would be best (and probabaly only) option for client to publish messages as json, and then for gateway to simply send the unaltered json messages forward.
I've seen that RawRabbit have the ability to take raw Json as message and then deserialize it to C# class.
What I can't find is some example and/or documentation of how the process should look like. Also cannot find documentation of how the Json message should be formatted.
I have a case with existing application. the application interaction with server using web sevice. But, nowadays the server change the request from web service soap into json. any idea how to transform/convert existing request from client (using soap xml) into json without change the code in client? maybe using api gateway or else
Solved, by using feature on ESB. Transformation Message.
I have a page, that page return StreamResponse (json):
StreamResponse onActivate() { .... }
Server support POST/GET/PUT/DELETE requests with parameters for that page.
I want write a test (junit) for this requests and assert results.
How I can did it?
For pre-Tapestry 5.4 there's a SeleniumTestCase that you can use to run integration tests for your app:
https://tapestry.apache.org/integration-testing.html
Note that Selenium RC that's used in SeleniumTestCase has been deprecated and new projects shouldn't use it.
Recent versions of tapestry recommend to use Spock + Geb for integration testing, one example can be found here. There's a 3rd party project tapestry-geb maintained by a Tapestry committer that can help you setup the Geb for your tests.
You can also start your app using PageTester, but as far as I know PageTester itself can't work with custom HTTP verbs, so you'll need to use something else for sending requests, i.e. using the same Spock + Geb.
Note that it's not something common to have a Tapestry page that responds to different HTTP verbs and returns JSON response. It looks like you're trying to implement some sort of REST API, in this case I'd recommend you to look at Tynamo's tapestry-resteasy.
With tapestry-resteasy you can expose a Tapestry service as a REST endpoint. In such case you can use above mentioned PageTester to test your the endpoint as a regular Tapestry service.
I'm new to REST Web based services and trying to understanding how the contract is created for JSON returned REST services.
From my understanding, any XML based SOAP/REST services will have a WSDL document.
What document is created for JSON based REST Services?
a REST web service doesn't have any auto explanation document like wsdl, you need to know how the webservice works, reading the documentation provided with it. Generally it works with common requests. Assuming that you have a products REST webservice, you could have:
GET /products -> read all products
GET /products/1 -> read the product 1
POST /products -> create a new product
PUT /products/1 -> update product 1
DELETE /products/1 -> delete product 1
but you have to know which parameters you need to send to any request. I hope I was clear...
Every HTTP response has metadata in HTTP headers. One of those HTTP headers is ContentType. The content type identifies a media type which is the contract that the response payload must conform to. The specifications for media types can be found here http://www.iana.org/assignments/media-types/media-types.xhtml
One of the major differences between SOAP and HTTP (as an application protocol) is that SOAP defines the contract at design time, whereas with HTTP the contract is specified in the response message so it can change over time. Therefore it is important for the client to read the content type on each response to know how to process the response.
There is WADL (http://en.wikipedia.org/wiki/Web_Application_Description_Language) although it is not so much used as WSDL for SOAP. REST services written in Java EE automatically generate it as .../application.wadl, PHP suppor is pretty poor as far as I know.
As the others mentioned a web service definition is not necessary for RESTful services, however if you want to create something similar for your API the industry standard is Swagger/OpenAPI, though GraphQL schemas are also becoming a defacto standard too.
There are also a few other options you can also explore (see wikipedia).
Here is a list of the most common options:
swagger.json or openapi.json files in the OpenAPI Spec
GraphQL Schemas with full spec here
Postman Collections which can be published online.
RAML
RSDL
We use org.json api to parse json on server side and GWT JsonParser to parse JSON on client side. Is there a api that we can use that can be used on both the client side and server side?
You are looking for GWT AutoBean: http://code.google.com/p/google-web-toolkit/wiki/AutoBean
With AutoBeans you juset define the structure of your JSON and the GWT Compiler handles the rest.
I am writing this in comparison to using autobeans or GWT-RCP - if you are using Java on the server. Especially so, if you are not.
The cleanest way is REST-RPC/JPA, where you can share a single set of POJOS between client, server and persistence db. Let me brag on behalf of this technology mix - one single set of POJOs, instead of three, without any (or minimal) transformation between the three fronts.
You should not have to write any data transformation routines. Or at least, only minimal amount of data transformation due to serialization constraints or because you are trying to interface GWT and REST with an existing schema which presents a high degree of non-serializability.
As well as, similar to GWT-RPC, sharing a single set of Java RPC methods on both client-server sides. Well, nearly the same set of methods. Except that the return type on the server-side becomes the callback generic parameter on the client-side.
The mix of technology is:
JAX-RS (either Resteasy or Jersey on the server side)
JAX-RS + GWT = RestyGWT on the client-side
JPA on the server-side
JAXB over JAX-RS on both GWT client and server-side.
Jackson JSON processor on server-side.
Compelling reasons for REST-RPC is
you could pretend you writing client-server conversations as GWT-RPC. The service interface and callback attitude is the same.
The data interchange between client and server is in JSON.
Which means you could use a browser instead of your GWT client to converse with the server after you have successfully set up your app. Or jQuery. Or PHP, or Python as the server.
no need to muck around with the JSON or XML encode/decode yourself - deal in POJO and only in POJO.
you could use the browser to debug your web service independent of the GWT client.
The attitude of REST is (besides state independent requests) is the concept called a Web API. An API like a javadoc, perhaps - but stated in terms of JSON or XML. The wonderful thing about this API is - you do not have to generate the documentation. Like a javadoc, you could run Enunciate over the service interface.
You could follow my discussion in the following (3+ part) blog post:
http://h2g2java.blessedgeek.com/2012/07/gwt-with-jax-rs-and-jpa-part-3.html.