I'm contemplating using Camel for my project and would like to know if it's feasable or camel is not a good choice.
I need multiple clients running same exact application to exchange information via web services (CXF or AXIS). The exchange will go through a central hub that will do a content based routing from one client to the other and will also log this communication in the database. The hub will also route one client's response to another when the responses come in. There could be a large amount of these exchanges going on from multiple clients.
The webservices are exactly the same so I don't need to integrate different systems.
I just need a routing mechanism and something that would control volume. Also ease of calling/accepting web service calls is important.
We are a Java/JBoss shop.
Is Camel a fitting solution for this problem or is it an overkill or is there anything else that would fit this requirement better?
I would greatly appreciate your help.
Thank you
Nadia
Yeah Camel can sit as this hub and route messages.
It support the EIP patterns
http://camel.apache.org/eip
There is plenty of components related to HTTP and WS
http://camel.apache.org/cxf
http://camel.apache.org/http
http://camel.apache.org/jetty
http://camel.apache.org/cxf
http://camel.apache.org/spring-web-services.html
And here is a little CXF proxy example
http://camel.apache.org/cxf-proxy-example.html
PS: There is a apache-camel tag which most people use for Camel questions
Related
I have a hypothetical web application which is split up into a microservice architecture like (as an example):
Clients A-C are web applications that serve HTML. Services 1-3 are the backend that handle CRUD and serve JSON. There are other clients (not pictured) that do not access Frontend Service - namely, native clients such as Android and iOS. I'm trying to figure out the best way to serve common frontend content (such as header/footer/css) across all web clients. The best way I can think of doing this is to create a Frontend Service that each web client can access to pull this common information. That way changing the common front end will be reflected in each application immediately without need to update versions, recompile or redeploy.
My question is what is the best way of doing this? I'm using Dropwizard to serve both the web clients and the services. The web clients serve Dropwizard Views (with freemarker templates) via Jetty. Is there a way to compose Dropwizard Views so that I can request a Header and a Footer view from Frontend Service and wrap these around each view returned from the Clients? Or am I going about this completely wrong? I know that Freemarker supports template inheritance but as far as I can tell this means the header/footer would have to live in each client or be pulled in from a common JAR (which would require updating version numbers and recompiling).
If you want to have content synchronized between all the microservices, in your case the header and footer, I'd suggest Zookeeper, it's designed for distributed orchestration and has more of a push model - i.e. you'd update the header in Zookeeper and all of your services would receive that update almost instantly.
I suggest the Curator library as it's much easier to work with than Zookeeper directly, the cache example might be a useful starting point.
You can also use Hazelcast as distributed Map/Cache. It is really easy to use (see code examples), but if you want some enterprise features you have to pay a lot.
This might be a silly question on this site, but I want to learn more about it.
Being in the Software Engineering field, I have come to know that it's useful to get acquainted with Web-Services. I am trying to understand it. To do so, I must know the difference between a Web-Service and a Application-Service in simple terms.
I have heard about SOAP & REST Services.
For a newbie like me, its overwhelming to understand these concepts when I search them in Google.
How to understand these things better and in what order?
I think it's a great and simple question which usually confuses most of developers. What is Application Service and what is web Service?
Web service is a common term which you can find easily on the internet. Although some time they cross each others boundaries but here is a simplest explanation I can think of:
Application service or Application Layer is an abstraction layer reserved for communications protocols and methods designed for process-to-process communications. Application layer protocols use the underlying transport layer protocols to establish host-to-host connections.
Some time you can also use Application Service to define method calls within your application.
WebService: Any application or method which can be accessed by web is a Webservice. You can also say: anything available on the web is WebService.
There are three common web service architectures:
RESTful resource-oriented,
RPC-style e.g. SOAP
REST-RPC hybrid. 90% of the web sites use this unknowingly e.g. http://mysite.com/get/pictures?tag=birthday :)
Me and some friends are going to develop a web site with playframework and a mobile application (android and iphone). So we need to make some webservices for the mobile application(CRUD). So we thought about using this web services in our playframework application instead of wasting time and creating the CRUD with anorm(writing all the sql requests).
Well, I'm here to ask for your opinion. Is this a good thing to do ? What's the best advised method here ?
Thank you.
PS: the web services are automatically generated with Netbeans from our database.
There are various reasons why I would advice against this approach.
A general design rule is not to expose your internal data model to the user. This rule comes in many flavors in which the layered architecture is probably the most known one.
In detail there will be issues like:
Tuning performance: This is hard to achieve because your have no, or not much control over the generated web services. When your application is really taking of your will suffer from this limitation
Access the service: I don't know whether you generate RESTful web services or WS-* ones. The latter will get you in trouble when accessing them via iphone.
Design Play vs. synchronous web services: Also somehow related to performance is the issue that the generated service is likely synchronous, blocking, which does not fit well with the non-blocking approach which the play framework is taking.
Abstraction level: Because your database is based on sets but your business model is likely not, you will have issues developing a decent client, tuning the performance, doing proper validation, security, etc.
Authentication, authorization and accounting: Hard to do because the database only knows the db system users
Change: What if you change your database model? Will the generated services continue to work? Do your have do adopt them event if you just add a column?
...
Some of those reasons do overlap, but I think the general problem should be clear.
Instead of this approach I would recommend the following. Develop a RESTfull endpoint for your app, which is not that hard to to. This is the external contract against which the clients should be developing. play-mini for example has a very need, Unfiltered based, API to do this. While doing this, focus on the operations your app really needs. CRUD in general is a bad model when thinking about production ready software.
How you access your database is another decision your have to make but probably it is not that important because it is not your external contract so your can change it when your have the need for doing so.
I am in the process of designing an application that users will be able to log on remotely and use - via a web interface.
Security is of paramount importance (think credit card and personal banking type information)- so I need to make sure that I get the security aspect nailed down - HARD.
I intend to provide the application functionality via traditional (stateful) web pages , as well as web services.
For what its worth, I am intending to use web2py as my web application framework.
Is there a list of guidelines I can follow to make sure that I have all areas covered?
One stop shopping: https://www.owasp.org/index.php/Main_Page
Read that and take every suggestion to heart.
you should consider at least the following:
authentication. getting users to log on in some manner. which authentication method they use depends on what you aim to provide
privacy. making sure the information they send is only visible to them and your application and not an eavesdropper.
in the simplest case SSL can take care of both of the above. it will always provide encryption but can also be used to authenticate or at least make some simple authentication mechanism more secure. one thing to look at is security of ssl. ssl is suceptible to a man in the middle attack particluarly when the users already have a trust relationship with, say, their employer - who can them proceed to install an ssl gateway which is effectively a mim.
authorisation. making sure users are only allowed to see what you want them to see and no more.
this really depends on technology you are using.
non reputidation. making sure the user cannot dispute the actions they perform
this is a very open ended question. legally this is seldom (never?) used so it depends... something like signed logs of user requested actions for example is probably enough.
Your biggest threat, by far, is writing server-side webapp code that introduces vulnerabilities in your web application layer. This is not something you can checklist. For a starter, make sure you are 100% comfortable with the items in the OWASP Top Ten and understand how to code safely against them. If you are not expert in web application vulnerabilities, strongly consider hiring someone who is to help review the web layer. At the least, i would consider contacting a security testing company to perform some form of penetration testing, preferably with a code review component.
If you ever do anything with credit card data, you will need to comply with the PCI DSS which will require at least quarterly remote-testing from an Approved Scanning Vendor.
We'll be developing mobile applications (for both iOS and Android platforms) that will be using web services. I'll be the one implementing the web services part and I plan on using Apache CXF.
It would be the first time I'm using CXF but I'm highly considering it because of its integration with Spring.
What are the potential issues (if any) with using CXF for mobile apps? If there are, is there supposed to be a better alternative to CXF? If there are none, any best practices I should also be considering?
Thanks!
I've been through the mobile ringer... WAP, J2ME, Brew, embedded languages, etc. Mobile development is exciting and also a bit scary...
Spring Integration: There is a big difference between * and **... be careful when setting up filters. It's easy to get out of hand securing end-points.
Authentication: How will your mobile devices authenticate and what is their role in Authentication, Authorization, and Access? Session management on occasionally connected devices - can get interesting. If a session goes stale how are you going to handle challenge / response?
App Security: Does your solution require SSL? Managing self-signed certificates is painful and time consuming. Do yourself and your mobile devs a favor and get a CA certificate in place up-front. You will save time (money) and a great deal of headache.
Proxy Power: Ideally, the people writing the front-end should be using an IDE that supports some kind of tethering for realtime debugging. Being able to add a breakpoint and introspect what's going on in the code... is mint. However, I haven't seen an IDE yet that gives front-end mobile devs the same experience as back-end devs. My guess is that your mobile devs are going all goo-goo eyes over jQuery. Understandably so! WebStorm and Aptana are good in the JS arena - but they're still evolving.
This is a problem front-end mobile devs need to work out... right? Yes... and no. Without proper tools everyone in the dev-chain will have to cook-up their own ways of answering questions like:
What did the mobile app send?
Was the request formed correctly?
What was the response?
Again, save yourself some time and finger-pointing and just sit down together (front and back-end devs) and work out a tech-stack that provides everyone optimal access to all app communications. Configurable logging on the server is a good idea to have in place from inception. Are you familiar with Firebug or Charles Proxy? A proxy can greatly simplify the debugging equation - just sayin'
Exceptions: Oh... and beware HTTP response codes. Exceptions on the server-side should be gracefully handled to prevent mobile consumers from choking on responses. Yikes - that's all I can say is YIKES!
Service / Life Cycle: Have you calculated the duration of the service and / or life cycle of your application? Knowing this can greatly impact architectural decisions.
Web Services: My knee-jerk reaction - is this the best technology for your product? Why Web Services? Can you come up with three concrete reasons why WS is the best option? From my experience, the most compact protocol will usually lead to the best user experience.
Food for thought... ASP.NET and JSon make a good pair.
http://encosia.com/using-jquery-to-consume-aspnet-json-web-services/
SOAP-XML is cumbersome. :-(
http://openlandscape.net/2009/09/25/call-soap-xm-web-services-with-jquery-ajax/
Have you considered RESTful Web Services? If you're using CXF... there are three different ways to build RESTful Web Services.
JAX-RS (CXF has an implementation of JSR-311 baked-in)
JAX-WS (more complicated - meh)
HTTP Binding (deprecated... may be removed from CXF in the future - fair warning)
More at: http://cxf.apache.org/docs/restful-services.html
Examples: http://solutionsfit.com/blog/2010/04/21/enterprise-mashups-with-restful-web-services-and-jquery-part-1/
Alternatives: There are so many great projects out there... Axis2 and Shiro come to mind. Without knowing more about your solution - it's difficult to recommend anything.
Final Thoughts: As a back-end dev, I would recommend getting familiar with the entire app tech stack and kick-off development with a series of small but functional samples that light the way through the obstacles mentioned above. Hold-on to the samples! They may prove useful in zeroing in on regression.
Mobile devices are getting faster and faster every day... it's true, but any dev worth their salt will know that they need to code to a common denominator if they want a mobile product to be widely consumed, adopted, and embraced.