I'm currently evaluating the suitability of LoopBack for a future microservice-based project. Moreover, I'm new to LoopBack, so please correct me, if a misunderstood the concepts of Loopback.
At times, you need an aggregator microservice which calls several others. Is it possible to generate a strongly typed client library stubs (in the form of a Service) analogous to the lb4 openapi command?
And if not, what is the point of using TypeScript (as advertized), when one has to use pure JavaScript as shown in these examples (1) (2)?
Also is there an option to use an OpenAPI spec file from existing services?
It seems to me that this is a 'terra incognita' at this point for LoopBack v4 with TypeScript.
Disclaimer: I'm a maintainer of LoopBack.
There are a few things involved here:
Communication between microservices - we support REST and gRPC via connectors, such as loopback-connector-openapi and loopback-connector-grpc.
As you mentioned, it's on the roadmap to generate service stubs - see https://github.com/strongloop/loopback-next/issues/1070#issuecomment-403530459. The lb4 openapi command has implemented a lot of logic that can be applied to lb4 openapi-stub. Contributions are welcome!
You should also check out https://github.com/strongloop/loopback4-example-shopping/pull/268.
Related
I am currently looking at redeveloping a web service that is currently written in .Net. I would like to port it across to Java using a CXF, Spring, Hibernate and Maven stack.
The WSDL for the service is already available and is well formed so I would like to reuse rather than redeveloping the interface. This will also mean that the clients will not require significant changes in order to use the new service.
I would like to use a JAX-WS type approach to developing the web service, similar to the Java-first approach at http://cxf.apache.org/docs/writing-a-service-with-spring.html. The only difference being that I would like to follow a contract-first approach and ensure that the exact WSDL is used.
Has anyone attempted this before? Are there any good guides online that I can refer to?
I am actually not seeing in your question what is stopping you from developing it with WSDL first approach.
Check my answer here, for the tutorials you need.
I guess its pretty straight forward (The WS stack part)
1.Create the Implementation stubs using WSDL (contract)
2.Create Client using WSDL
* implement methods using your own logic and syntax
both 1&2 is supported by CXF.
good guides here
and here
One of our product publishes a webservice using contract-last approach. This has becoming a real problem as all of our clients (ws clients) have to rebuild their client apps as soon as we release a new version of our product. This is due to all namespace changes that comes as a cost with auto-generated wsdls. We use Axis1 for javatowsdl. I've been seeking for a good methodology/ tool to develop backward compatible webservice for this.
i.e. version 9.3 clients can still hit the 10.0 service, of cause they will miss some of the functionality, that is fine. But they should be able to function without breaking.
I do understand the whole problem is due to our contract last approach (Pls. correct me if I'm wrong). Therefore, if the solution is to go for contract-first webservice what are the tools and technologies I could use? Also what are the best practises around contract-first?
Thanks in advance.
As you already realized, the recommendation is to use a Contract-First (or Top-Down) approach to develop Web Services. That implies a manual definition of your WSDL interface and generate a Java Skeleton of the Web Service based on this document using automatic tools.
Is important that your WSDL complies to the WS-I standart to assure interoperability between clients on different platforms. You can use SOAP-UI to test whether your WSDL is compatible with the standard or not.
For the Skeleton generation, there are several Web Service Runtime API's that you can use: Like Apache Axis and JAX-WS. I personally prefer JAX-WS because is a Java Standard and is supported by all Java EE Containers. Each container provides tools for the Skeleton generation, Weblogic has some nice Ant Task for that but there's also WS-Import that is Container neutral.
I am working on a Java EE project where there is a need to incorporate Web Services to transmit and receive data to/from external sources. I am not sure which way to go, Axis2 or JAX-WS.
Any suggestions will be appreciated.
The choice of a web services stack depends on what standards you actually need. Here are some stacks currently available:
The JAX-WS reference implementation is part of Java and provides basic support, including WS-Addressing, but not WS-ReliableMessaging or WS-Security. The big advantage is that you do not get additional dependencies by using the RI.
Another option is Axis2, which also provides support for these standards. As far as I know, the use of Axis2 is declining and personally, I found it rather hard to use (That's basically an opinion, I do not want to start a flame war).
I would suggest to consider a third option: CXF. It is another implementation of a web service stack and supports roughly the same as Axis2. I found it rather easy to set up and use and personally prefer it to Axis2.
One more option is Metro. Metro bundles the JAX-WS reference implementation and the Web Services Interoperability Technologies (WSIT). WSIT provides an implementation for several more standards and is tuned to provide interoperability with WCF.
Here is an article that compares these stacks with a little more detail. My suggestion would be: If you only need basic stuff (no reliable messaging, security, etc.) use the reference implementation. If you need support for additional standards, go for CXF or Metro.
Metro is the way to go! At lest for me :)
please see my comment in a similar question.
It depends on your requirement. What type of implementation you require.Java from its 1.6 version provides API for JAX-WS type of web service creation. But, really it's just for the basic requirement. If you want ws-Security,ws-policy etc. then please go for Axis2. Actually in Axis2 they have made lot of improvement from it's Axis 1.x version. The new STAX implementation is one of them. Apart from that Axis2 has made service creation part lot easier. Even, they support RESTful web services also.
I am a noob to web services world. I need to develop a login validator module and expose it as a service. I want it to be service independent, i.e I should have the option of exposing it as a SOAP service or REST service in the future.
What pattern should I follow ? Sorry if I am unclear in my requirements, I can clarify as per need.
Thanks !!
Edit : I am using Eclipse as an IDE and Jersey libraries. I am not into any framework, simply using the MVC pattern. I find a lot of difference between SOAP ann REST methods, so I want my methods to be implementation independent - i.e I should be easily able to use my method through a SOAP or REST service call as per need. What should I do for maximum flexibility ?
Picking a good MVC framework and understanding how to use it properly can help ensure that your feature is "service independent". Most of the documentation I've read for good frameworks suggest that you keep your business logic separate from your controller.
If you read the documentation for the tools that you use, and ensure that there is a layer between your business logic and your controllers, then that will make the job of switching from SOAP to REST or some other protocol much, much easier.
Since you mentioned you're using Eclipse in your comment below, I'm assuming you are using or are willing to use Java:
Restlets
http://www.restlet.org/
Spring 3.0 REST
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
Develop your service as a POJO. Make sure to respect staless pattern.
Create an EndPoint class for each publication type you require (Soap, Rest, EJB, JMS, what ever)
Use appropriate standard to expose your EndPoint. For Soap and Rest the JAX-WS api and implementations can do it for you using java annotations on your EndPoint.
That's it !
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.