I would like to understand whether we really have any tool to convert the WSDL to RAML for migrating the project from SOAP to JSON.
Share with me the tool if we have any.
There maybe some tools that perform a translation between WSDL and RAML but the standards are significantly different and any automated translations can be partial only. You are probably going to need to complete manually the translation. You might get better results by starting a RAML version from scratch without the artifacts left by a tool.
Related
this seems pretty basic, but I am rather new to web development so I am a bit stuck here. I have MongoDB running on the backend, which contains geo-spatial objects that in the front end should be displayed on a map. The communication between backend and web frontend is where I have knowledge gaps.
The user should be able to zoom to an area on a map that he is interested in, then press "Search". The backend would then find every entry in the database that has coordinates that are on the users current screen. It would transmit these to the frontend, ideally as a list of JSON objects. The frontend displays these on a map.
I have a front end mock up, code that puts data into MongoDB and code that queries MongoDB. I know that I am missing a server that can be queried from the frontend. I thought I use Jetty. But what do I need to do then? I guess I need Jetty to provide a JSON API that I can query from JavaScript. Could someone point me to the Jetty class or interface that I need to implement and maybe give a few lines of code on how to query this from JavaScript?
You have a very open question here.
To start with, Jetty is merely a Java Web Container (following a subset of the Java EE Web Profile), while it does have some AJAX/JSON capabilities, it is extremely fundamental and not hooked up into any sort of query API.
You would do better do use Jetty along with a proper REST/JSON API library for your project.
Some examples (these are not the only choices available):
jersey - Jersey - an Open Source JAX-RS (JSR 311) implementation for RESTful web services, with JSON Support - Here's Lars Vogel's Tutorial on JAX-RS using Jersey.
restlet - Restlet - another RESTful web API, with a JSON extension
resteasy - RESTEasy - another JAX-RS implementation for RESTful web services, with JSON marshalling.
Also note that there are many flavors of Java based JSON APIs and Libraries, you should probably be aware of them as you will encounter them in your journey to success.
In the end I found the Dropwizard framework (there might be others), which does a lot of the work that is necessary to get a simple JSON API up out of the box:
http://dropwizard.io/
I am currently implementing a set of web services intended to be used by JavaScript clients and am using Google Gson for JSON serialization/deserialization. My service contracts are thus defined in Java classes. I now need a way of generating documentation of these message interfaces in a way intended to be used by JavaScript developers.
Ideally, I would like a tool along the lines of JavaDoc that generated JSON examples, JSON schemas or other Web developer friendly documentation of my types, that could easily be integrated with Maven to produce HTML based documentation for types with a certain annotation.
I can point them to the generated JavaDoc, but it will require them to understand and hunt through all private fields to work out how to format requests, and also does not take into account Gson type converters etc.
Are there any relevant tools available in this area?
I have used Swagger in the past. It is simple to implement, yet generates powerful API doc.
Please look at this documentation. I think this is what you are looking for.
http://petstore.swagger.wordnik.com/
I've been looking at asp.net Web Api, and I like the simplicity of implementing a practical web service.
However, how can I document/specify the interface of a service implemented like that? For example, is there any spec I can pass on or generate to a Java guy with no .NET background that will let him easily call and consume the service? What can I give to the javascript guy?
Ideally, I'd like the benefits of SOAP/XSD or something like it (easy to deserialize with nicely typed objects) for the java guy, while retaining a service that's callable from a web browser too (i.e. supports non-crufy JSON).
Update
It's worth noting that since I originally posted this question, I discovered ServiceStack which deals with this more naturally; supporting JSON, SOAP, and WSDL out of the box for the same service, as the client chooses. If you really want SOAP+JSON, it may be a better framework than ASP.NET Web Api.
Update March 2016
It has been a while since this was answered and the tooling for documenting any Rest API has come along a lot. We are currently evaluating Swagger 2.0 now spawning out to the the Open Api Initiative, RAML and API Blueprint.
For WebAPI projects there is a tool Swashbuckle that auto creates Swagger (Open API) format documentation.
Format for documenting a REST service:
There are some attempts at structuring and standardising the description of REST services:
Web Application Desciption Language (WADL)
Web Service Description Language 2.0 (WSDL 2.0)
I think it is fair to say neither of the two approaches above have very wide adoption, but WADL does look like a nice concise format - a quick XSLT over the top and it could be a nice human readable format. There lots of examples of WADL for some famous API's at the apigee github site here.
When trying to find a documentation format that is appropriate I tend to look for "inspiration" from others.... Apigee do a lot of research in this area and have this as documentation for one of their API's here or take a look at Facebook's social graph api here.
The examples are largely in line with the advise here
How to auto document:
Using .NET: There is a good example of auto generating a WebApi "help" page here. A logical extension of this example may be to get it outing a WADL formated version as well...
Using Java: Jersey is a tool used in the Java community to generate WADL automatically.
What to share with the other developers:
Your Javascript guy will most likely want a manual like the Facebook and apigee one; giving the dev examples of the resources, urls, response codes etc. The most important thing here will be supporting JSON as the primary content type this will be the easiest for him/her to consume and work with by far.
Your Java guy would also want the manual, but also in theory they could be given example XSD for any XML representations of the resources you send/consume (assuming they make the request as "Content-Type: appplication/xml"). This may help them build proxy classes etc. JSON to Java and .NET converters are available online and given the example resources in your manual they should simply be able to use one of these types of services to quickly create proxies. Generate Java class from JSON?.
If you absolutely must have auto discovery, auto proxy generation etc then you may need to offer a choice of both REST and SOAP (with WSDL) endpoints - relevant question here: ReST Proxy Object Generator.
You can use IApiExplorer interface and ApiExplorer class in order to create a help page for your Web Api service. This help page will describe the REST methods exposed by your service so any developer who understands how REST works will be able to use it (regardless the language). Please read below links for details and samples:
ASP.NET Web API: Introducing IApiExplorer/ApiExplorer
ASP.NET Web API: Generating a Web API help page using ApiExplorer
Documenting your ASP.Net Web API’s
I am searching for the best 100% open source ESB for the following requirements, after searching I'm confused between Servicemix and WSO2/synapse
1- The requester is mobile app that requires all services to be exposed via REST (JSON objects)
2- Many back end providers (JMS, SOAP, SMTP, LDAP, ...)
3- Provide easy way and flexibility to transform and perform complex business logic
4- Security and Caching
5- Above all easy to learn, use and extend with small learning curve and good tutorials and community support
Thanks,
I think you can achieve what you want with both of these. You might even want to look at the similar Mule ESB CE which is as well open source.
However, considering you want a flexible solution that is easy to learn, but not limited, then I would go for Service Mix and deploy various Camel routes to it. Camel is, imho, probably the easies and most well documented open source integration engines out there and I really recommend it.
In the end, it's a matter of taste. WSO2/synapse has it's base in web services, and you might feel better there if you are more comfortable with XML standards (including SOAP,BPEL..) than java programming (which is sort of needed in SMX/camel).
what is difference between JBPM and BPEL(and ESB)?
Would you please explain them?
RGDS
I am not much familiar with JBPM. But it seems to be a Business work flow which can work with java services or basically java based process. Not only with web services.
BPEL is a standard to write work follows with web services. Always BPEL language used to integrate the web services and define processes based on that. Here is an sample I have written for that[1].
ESB is primarily used for mediation and transform messages. When you integrate different types of systems, the message flow between them may vary. So people can use ESB as a mediator. And also some ESBs provides service integration as well. WSO2 ESB[2] is such an ESB you can use.
[1] http://wso2.org/library/articles/2011/05/integrate-business-rules-bpel
[2] http://wso2.org/library/esb
Exactly, ESB + BPEL is a technical solution for an integration problem. If you want to use jBPM5 just to do integrations thats fine and you probably will use jBPM5 with an ESB for all your mediation and transformation of your messages. The power of BPMN2, a standard notation to describe business processes will help you to describe more high level/business oriented scenarios than just simple system integrations. The concept of human interaction is heavily embedded in the language and in the jBPM5 infrastructure. Think about the fact that your models (business processes) can be shared and understood by business/non technical people and they will be able to validate, improve and change those definitions when the business reality changes.
Hope it helps!
jBPM is BPMN based. This is a java based solution to your workflow problem.
BPEL is also solves the workflow problem, but the approach is entirely different. It is web service based.
BPEL from a syntax perspective is more complex than BPMN but is considered more extensive.
The right comparison should actually be between BPMN and BPEL I guess.
Similarity
>Both can be used for orchestration
difference in terms of technology.
JBPM has BPMN2.0 Notation for Workflow designer and workflow XML it generate is BPM2.0 compliance(which means you can import it in any BPMN2.0 tool) .It is assumed to be Product Analyst friendly whereas BPEL has its own specifications and its considered more developer oriented
BPM should only be used where there is a human task otherwise ESB fulfills everything from orchestration to transformation to Rules to CEP