I'm trying to study how Spring Integration works (with extramly difficult, on the net there are a tons of source code but without some real step-by-step tutorial) and i would like to use it in my own application.
I will have to write a client/server application where the server endpoint is a Webservice and the client will be a Standalone app.
The standalone app will collect some data (creating different POJO, because each kind of that have different members) and next will invoke a WebService that store it in database.
The idea is to have a single REST Endpoint on WebService, in this way i dont have to create different one if i will have to expand my Standalone app.
My problem is: because the Endpoint will be only one, there is a way to apply some "transformation" when the webservice is invoked so i can manage different data?
For example:
Standalone app collect data (class1) -> Invoke webservice -> Webservice apply some transormation regardless Class1 type -> Save the data
Standalone app collect data (class2) -> Invoke webservice -> Webservice apply some transormation regardless Class2 type -> Save the data
So, each class have its own "transformation" that know what to do with this data.
A better real example could be this:
Class1 - Is a class with a single member (a String)
Class2 - Is a class with two member (a String and a Integer)
The Standalone App invoke wbs passing it Class1, the wbs with (transformation?) manage Class1 and store the data
The same process will be replaced to Class2
Doing this flow, when later i will have to expand this applications, i will have to write only the transformation (on wbs side) and how the data have to be collected (on Client side).
Someone could show me some starting point (tutorial, examples ecc) on this kind of argument ?
Unfortunally, with my low experience with SI i really dont know where to start with this argument. I just have seen that this framework have a lot of functionality and maybe exists something that handle this.... but i dont know how to find :(
I suggest you familiarize yourself with the Enterprise Integration Patterns and read the Spring Integration Reference and look at the samples.
In your case, you could use a Payload Type Router to route the messages to different flows based on the inbound payload type.
Creating a step-by-step tutorial for every use case would be an enormous task.
We're happy to help further if/when you have specific questions; consider contributing a sample when you get it working.
Related
I've recently read about the advantages (and disatvanteges) of GraphQL over Rest API.
I am developing a webpage that consumes several different Rest APIs and Soap services. Some of those services are dependent, meaning that a result from Rest1 will be passed as a parameter to Rest2 which will be passed to Soap service for a final return value.
From what I understood, GraphQL deals with multiple data sources and query nesting, but I have not yet understood if it will handle those nested dependent queries.
Can anyone that worked with several data sources that are dependent with GraphQL tell me if it can be done? My project should be up in 2 weeks and investing time in learning and setting up GraphQL and ending up not using it because it's not supporting my case would be a big failure for me.
Note: the APIs and services are not mine, I am consuming them from an outside source
I'm assuming you haven't yet setup a GraphQL server. Once you do, you can see how this isn't too difficult. So, I'd recommend you setup your own server first. The Egghead Course, "Build a GraphQL Server" got me started, but it's not free.
In essence, you'll be setting up your schema then defining how to resolve with data. When you resolve, you can setup an express server to query a database, or you can hit a REST interface, or hit your SOAP interface. How you retrieve the data is up to you, so long as you return it in compliance with your defined schema.
Hope that makes sense. Mocking up a mini app to demonstrate is possible, but since I don't have one handy, this is the best advice I can offer.
We have a huge enterprise application wherein the users navigates through application registration, data entry and finally some results based on the data processing. Currently the navigation logic is handled in java classes; depending on data entered, user action etc the next page to navigate to is decided at each step.
We decided to implement spring web flow to implement the navigation. However, we are not sure if we can cover all possible scenarios beforehand and create a flow considering all the scenarios.
Hence, we are looking for a way in which we can dynamically create the flow at runtime depending on different conditions in the application. How can we accomplish that in SWF? Any help would be highly appreciated.
Under the covers, Spring WebFlow uses a flow registry (FlowDefinitionRegistryImpl) to handle mapping of url's to internal resources. Internally, the flow registry is (ultimately) a wrapper around a hashmap.
I believe that a flow that is defined at runtime is beyond the scope of Spring-weblow out of the box.
However, given enterprise resources, you can extend FlowDefinitionRegistryImpl or implement FlowDefinitionRegistry with a custom class that behaves like you want and allows you to change the flow "on the fly". You would need to pay attention to performance and synchronization, and define a mechanism for refreshing the underlying Map.
I've been developing a GwT application as a project for my computer science faculty.
It consists in 2 or 3 hosts running it, each of one has a client and a server and it is designed for a company renting cars which has 2 or 3 different points in a town.
So each point of renting has got its own client/server in the same host.
The problems comes out when point A has finished the cars to rent and needs to ask for some of them to point B or point C. So GWT application of point A needs to access the remote database in hosts of point B or Point C.
As database we use Objectdb because it's very simple and efficient and we use Spring to better interface between database and application. I've learnt that with Spring it's possible to create REST services to access the other remote databases via URL...I would need some explanation on how to do it, or a simple guid.
Can you help me?
Simply you want to make request doGet to any server and get the response data and on the other hand a request handler on the server to handle the request and reply with data
data is handled as JSON object
Package com.google.gwt.http.client
is providing the whole process for you
you can explore the pacakge here
and here is good tutorial from Google step by step to describe the whole process
My company needs to migrate data from a Taleo system to a new HR system.
A little research suggests that traditional ETL may not work against the Taleo cloud based system, but I don't know enough about the setup and am trying to learn.
Does anyone have experience migrating HR data from Taleo to another system, and, if so, how did you do it, and was traditional ETL an option?
Thanks
How you access Taleo depends as much on your platform as theirs.
Example: I'm using Windows:
not sure if this is my mistake ~~ vs2010 Add Service Reference fails
Taleo has just released a new version that as has killed a number of companies temporarily.*
Whether your ETL is one time or continous, Taleo provides a .PDF version of their API that works as follows for employee records (I'm only grabbing their employee records). Other records appear to use the same paradigm.
Employee records have two types of fields: fixed and user defined. The fixed fields which I work with in c# are like simple properties of a class and can be accessed with standard .name notation such as taleoItem.ManagerId. The user defined names are in list of "beans" ... for each bean, one looks first at its name ( *foreach (var taleoItem in taleoEmployeeBean.flexValues) ... if (taleoItem.fieldName == "Social Club Member") { ... ). * currently I'm getting zero of the 50+ flexbeans that I normally get and two flexbeans that I've never before seen. as can be expected, until Taleo fixes this breakage, all that I can to is twiddle my thumbs
When Taleo works properly, retrieving data generally works like this.
access a fixed url to get a url for your company;
authenticate via the url retrieved from step 1 to get a session token.
use the session token from step 2 to invoke the various Taleo API methods.
Warning: the Taleo API has documentation errors. Also, the test cases will not necessarily work.
I'm not familiar with Taleo, but according to their website they have features that allow integration via "XML, Web Services, reusable components, and standard APIs". There are many ETL tools on the market that can interface with web services as a source, or you could optionally write your own.
Taleo provides a PDF which described all the calls that can be made. Basically Taleo uses SOAP as web-service for accessing their data.
For a detailed description visit Taleo Integration in Drupal
I am planning a new application and have been experimenting with GWT as a possible frontend. The design question I am facing is this.
Should I use
Option A: GWT-RPC and build the app quickly
Option B: Build a REST backend using Spring MVC 3.0 with all the great #Controller, #Service, #Repository annotations and build a client side library to talk to the backend using the GWT overlay features and the GWT Request builder?
I am interested in all the pros and cons and people experiences with this type of design?
Ask yourself the question: "Will I need to reuse the server-side interface with a non-GWT front-end?"
If the answer is "no, I'll just have a GWT client": You can use GWT-RPC, and take advantage of the fact that you can use your Java objects both on the server and the client-side. This can also make the communication a bit more efficient, at least when used with <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />, which shortens the type names to small numeric values. You'll also get the advantage of better error handling (using Exceptions), type safety, etc.
If the answer is "yes, I'll make my service accessible for multiple kinds of front-ends": You can use REST with JSON (or XML), which can also be understood by non-GWT clients. In addition to switching clients, this would also allow you to switch to a different server implementation (maybe non-Java) in the future more easily. The disadvantage is, that you'll probably have to write wrappers (JavaScript Overlay Types) or transformation code on the GWT client side to build nice Java objects from the JSON objects. You'll have to be especially careful when you deploy a new version of the service, which brings us back to the lack of type safety.
The third option of course would be to build both. I'd choose this option, if the public REST interface should be different from the GWT-RPC interface anyway - maybe providing just a subset of easy to use services.
You can do both if use also use the RestyGWT project. It will make calling REST based JSON resources as easy as using GWT-RPC. Plus you can typically reuse the same request response DTOs from the server side on the client side.
We ran into the same issue when we created the Spiffy UI Framework. We chose REST and I would never go back. I'd even say GWT-RPC is a GWT Anti-pattern.
REST is a good idea even if you never intend to expose your REST endpoints. Creating a REST API will make your UI faster, your API better, and your entire application more maintainable.
I would say build a REST backend. In my last project we started by developing using GWT-RPC for the first few months, we wanted fast bootstrapping. Later on, when we needed the REST API, it was so expensive to do the refactoring we ended up with two backend APIs (REST and RPC)
If you build a proper REST backend, and a deserialization infra on the client side (to transform the json\xml to GWT Java objects) then the benefit of the RPC is almost nothing.
Another sometimes forgotten advantage of the REST approach is that it's more natural to the browser running the client, RPC is a propitiatory protocol, where all the requests are using POST. You can benefit from client side caching when reading resources in the standard way.
Answering ams comments:
Regarding the RPC protocol, last time I "sniffed" it using firebug it didn't look like json, so I don't know about that. Though, even if it is json based, it still uses only the HTTP POST method to communicate with the server, so my point here about caching is still valid, the browser won't cache POST requests.
Regarding the retrospective and what could have done better, writing the RPC service in a resource oriented architecture could lead later to easier porting to REST. remember that in REST one usually exposes resources with the basic CRUD operations, if you focus on that approach when writing the RPC service then you should be fine.
The REST architectural style promotes inspectable messages (which aids debugging and security), API evolution, multiple platforms, simple interfaces, failure recovery, high scalability, and (optionally) extensible systems via code on demand. It trades per-interaction performance for overall network efficiency. It reduces the server's control over consistent application behavior.
The "RPC style" (as we speak of it in opposition to REST) promotes platform uniformity, interface variability, code generation (and thereby the ability to pretend the network doesn't exist, but see the Fallacies), and customized interactions. It trades overall network efficiency for high per-interaction performance. It increases the server's control over consistent application behavior.
If your application desires the former qualities, use the REST style. If it desires the latter, use the RPC style.
If you're planning on using using Hibernate/JPA on the server-side and sending the resulting POJO's with relational data in them to the client (ie. an Employee object with a collection of Phones), definitely go with the REST implementation.
I started my GWT project a month ago using GWT RPC. All was well until I tried to serialize an object from the underlying db with a One-To-Many relationship in it. And got the dreaded:
com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy
If you encounter this and want to stay with GWT RPC you will have to use something like:
GWT Request Factory (www.gwtproject.org/doc/latest/DevGuideRequestFactory.html) - which forces you to write 3+ classes/interfaces per POJO you want to share with the client. OUCH!
Gilead (sourceforge.net/projects/gilead/) - which appears to a dead project.
I'm now using RestyGWT. The switch was fairly painless and my POJO's serialize without issue.
I would say that this depends on the scope of your total application. If your backend should be used by other clients, needs to be extendable etc. then create a separate module using REST. If the backend is to be used by only this client, then go for the GWT-RPC solution.