I'm trying to figure out exactly what an ESB is and how it is implemented. I understand that it is a bus that providers and consumers plug in to so that they can communicate.
Does an ESB consist of several servers and a provider/consumer can connect to any of them?
If so, are all these ESB servers interconnected?
Do they all provide access to the same contracts?
Does something like websphere run on all these servers?
I'm confused and need some clarification.
ESBs are implemented on commodity application servers, for the most part. Mostly EJB framework...
Most mature app servers have built-in clustering support, so you can think of an ESB as a big EJB application that creates (yet another) middleware abstraction for business communication. The technologies (web services, messaging, database access, etc.) are standard issue Java ecosystem recipes.
Related
I'm currently working on an architecture with an offline mobile client and a database server.
I was thinking about using the sync-gateway component from couchbase, hence, couchbase as a server db and pouchdb as a client db.
The business logic is quite complex, though and as far as I understand, synchronization filtering, data validation and authorization is made through the gateway configuration.
Is this a good idea or couchbase synchronization capabilities are preferred for simpler logics and I should stick to a more Spring Rest API and fill the local indexDB manually.
Couchbase Sync Gateway is used in very large enterprise grade deployments of varying complexity and scale so that shouldn't be an issue. The decision you would need to make is whether you need sync or you are looking for a simple request-response approach (that's better suited for connected environments). FWIW, Sync Gateway also supports a REST interface - so you can use indexedDB requesting data via the REST interface as well.
You mention offline mobile client so why are you not using couchbase lite as the embedded database? Is this a PWA? The synchronization protocol between Couchbase lite and Sync Gateway is more performant and advanced compared to the couchDB based approach used between the likes of PouchDB and Sync Gateway.
I am new to Couchbase and trying to understand why we need a Client side proxy like Moxi if using a Couchbase PHP SDK.
As per my understanding the proxying of client requests to right server is done by the Client SDK which maintains the vBucket map of all keys.
Why in case of a web application using PHP SDK and Couchbase, we need an additional Moxi client?
They are for two different things.
Moxi is for when you want to use a standard memcached library as MOXI will proxy memcached calls to the Couchbase cluster and use Couchbase buckets. Your code will not know it is talking to a persistent database in the background. Using moxi with Couchbase buckets will give you some of the benefits of Couchbase, like High Availability, easy scalability and performance Couchbase is known for, but you can use any old off the shelf memcached library. Just know that because of adhering to memcached, moxi is limited to that functionality from an application perspective.
In my opinion, moxi should be used to bridge the gap between people on memcached and using the full SDKs and is not meant to be a final destination, though some people have been on it for years.
Using the Couchbase PHP SDK on the other hand gives you the full suite functionality that Couchbase can offer and you do not need MOXI at all.
In summary, if you are in a spot to use the Couchbase SDK, do that. You will get more functionality, performance, etc. from it. Moxi is for those that are already have memcached, but want to step up to a clustered high performance cache and not change their code.
My web application uses PHP/MySQL on the server side to fetch and store data in a database. The DB size will increase with the user base, and can be huge. The application has been built and run on a conventional server, i.e no "cloud" specific code has been written (I have no experience with cloud systems; Is running services on them any different from running on a normal server?)
My concerns:
1. If I buy space on Amazon Elastic Compute Cloud, can I directly port all my code to the new server, or do I have to use some APIs specific to that? Since it's pay as you go, it's highly suitable for such a requirement.
2. What are the other options for hosting a web service that would require large server space? How might apps like Whatsapp be doing the same?
Thanks.
1) The answer to the first question depends on the type of service you're buying. Cloud comes in many forms, from Infrastructure as a Service (which basically offers you hardware as a service on which you can run your software stack) to Software as a Service (e.g. Gmail, which lets you use applications (or APIs) hosted in the cloud ).
The best alternative, in your case I think it is Platform as a Service (e.g Heroku) which defines a set of technologies supported by the provider and how to use them.
Either case, how difficult it is depends on your app and the specification of the service and the level of support offered, so you have to dig a little deeper (starting with guides of how to deploy a similar app would be a good choice).
2) Startups and other medium size companies use cloud providers such as Amazon, Rackspace etc and when they reach a certain size tend to build their own data centers (e.g Zynga). There's a threshold beyond which is better to manage your own infrastructure instead of buying services from others.
I am working on creating a spec for a startup to create a financial broker check website. It involves storing information about financial advisers and payment details of the users (so obviously needs a lot of security). What kind of databases are best suited for the application. Is MySQL or its open source variations enough or is it better to go with Oracle Enterprise etc. Also any info about the usefulness of application servers over traditional web servers (cloud based or normal) in this scenario and the preferred scripting language (PHP, Ruby, Python) for secure web applications.
Your choice of language, database, etc. has a relatively small impact on the security of your application. The developer's understanding of how to write secure code and the developer's understanding of the features provided by their tools is far more important. It is entirely possible to write a secure application on an open source LAMP stack. It is entirely possible to write a secure application on a completely closed source stack. It is also very easy to write insecure applications on any stack.
An enterprise database like Oracle will (depending on the edition, the options that are licensed, and the add-ons that are purchased) provide a host of security functions that may be useful. You can transparently encrypt the data at rest, you can encrypt the data when it flows over the network to the app server, you can prevent the DBA from viewing sensitive data, you can audit the actions of the DBA and other users, etc. But these sorts of things really only come into play when you've written a reasonably secure application to begin with. It does you little good to encrypt all the data if your application is vulnerable to SQL injection attacks and can be easily hacked to present all the decrypted data to the attacker, for example.
I have a client asking this for a requirement and haven't done this before, what does he mean by web service infrastructure?
That phrase encompasses a wide variety of technical aspects. Your infrastructure is all of the components that make up the systems that run a web business or application, including hardware. So it refers to your server and network setup, your bandwidth and connections in and out, your database setup, backup solutions, web server software, code deployment methods, and anything else used to successfully run a web business with high reliability and uptime and low error and bug incidents.
In order to make such a thing scalable, you have to architect all these components together into something that will work smoothly with growth over time. A scalable architecture should be flexible enough to handle sudden traffic spikes.
Methods used to facilitate scalability include replicated databases, clustered web servers, load balancers, RAID disk striping, and network switching. Your code has to take much of this into account.
It's a tough service to provide.
First thing that comes to mind was the Enterprise service bus.
He probably means some sort of "infrastructure" to run a lot of complex interacting web services.
Either an enterprise application that you call via a web service that can run on many instances of a web application server, or run a single instance that are very nicely multithreaded and scale to many CPUs, or deploying loads of different webservices that all talk to each other, often via message queues, until you have something that breaks all the time and requires a huge team of people to maintain. Might as well throw in a load of virtual machines to have a virtualised, scalable, re-deployable web service infrastructure (i.e., loads of tomcats or jbosses in linux VMs ready to deply as needed, one app per VM).
Then there is physical scalability. Is there enough CPU power for your needs? Is there enough bandwidth between physical nodes to send all these messages and SOAP transactions between machines? Is there enough storage? Is the storage available on a fast, low latency interconnect? Is the database nicely fed with CPU power, bandwidth, a disc system that doesn't lag. Is there a database backup. How about when a single machine can't handle the load of a particular function - then you need load balancers, although these are good for redundancy and software updates whilst remaining live as well.
Is there a site backup? Or are you scaling globally - will there be multiple data centres around the globe? Do you have redundant links to the internet from each data centre? What happens when a site goes down? How is data replicated between sites, to reduce inter-site communications, and how do these data caches and pushes work?
And so on and so forth. But your client probably just wants a web service that can be load balanced without thrashing (i.e., two or more instances can share data/sessions/etc, depends on the application really), with easy database configuration and backup. Ease of deployment is desirable, so make the install simple. Or even provide a Linux VM for them to add to their VM infrastructure. Talk to their sysadmin to see what they currently do.
This phrase is often used as a marketing term from companies who sell some part of what they'll call a "scalable web services infrastructure".
Try to find out from the client exactly what they need. Do they have existing web services? Do they have existing business logic they've decided to expose as web services? Do they have customers who are asking to be able to access your client's systems through web services?
Does your client even know what a web service is?