A webselfservice can easally be hosted in The Cloud.
The Cloud is like The Matrix. Is a worldwide network of computers, running virtual machines.
Everything in the cloud is virtual, but the servers living in The Cloud are not aware of this. So they run software like they were any physical server.
The good thing about The Amazon Cloud is that one can maintain their own servers like a virtual datacenter. Switching on a server is done with a click of a button.
Amazon has 2 datacenters in Europa, so they can guarantee that the data resides in Europa; which might be usefull in relation to legal issues.
Becaus the serves are completely virtual, and thus can run on any piece of hardware, the availability and scalability is high (or can be made high easally).
Up-scaling an existing server is easy and just takes a few hours.
Since the management of the servers is done by the customer, the customer can determine the level of support (and thus save money).
donderdag 26 maart 2009
The Cloud
dinsdag 24 maart 2009
SOA, webgateway and selfservice
Many companies are adapting SOA for various reasons.
If a company wants to create a public service, the SOA infrastructure could be a great platform for such a project.
In order to expose the existing SOA services to the internet, a couple of issues have to be addressed:
- Browser support
- Characteristics of on-line generated load
- Identity Management (authentication)
- Security (Authorisation)
These issues can be addressed by something I call a WebGateway.
Let me elaborate a bit on these issues.
The first and most import is support for browsers.
In order to reach a broad spectrum of users, all browsers should be able to use the exposed services. The 'old' way to do this is to expose the services using (D)HTML. A common way to do this is through a web application that generates HTML (like PHP, JSP, ASP, etc).
The downside of this is that the developer who creates the public service also determines the layout of this service (let's call this Web 1.0).
A new way to create public services is through REST style services, JSON or XML over HTTP.
This way, only the bare data is exposed, which enables frontend developers to use all their creativity to develop a slick and flashy website (let call this Web 2.0). Newly developed SOAP javascript libraries may give SOAP another chance on the internet.
The second issue is the load characteristics of on-line users in comparison to the way internal users are using the services.
The main difference is of course the number of users. For companies that offer public services (like telecom-, energy- and insurance companies) the on-line user base may be a 3-4th order bigger than the number of internal users (typical numbers for dutch companies are for B2B : 1000-10.000 and B2C : 10.000-2.000.000 users) .
In most cases where back-office system (mostly ERP or some kind of CRM/Customer Support system) are exposed by creating SOA services, the back-office systems are not designed for on-line use. Increasing the number of request by a factor 1000 or so may cripple the system and may render it unusable for the rest of the company (e.g. Customer Support).
This can be addressed by caching data in the WebGateway. The ways the cache can maintained will be discussed in a future blog.
The idea is that the WebGateway will try to serve as much data from its cache in order to decrease the load on the SOA services.
If customers are allowed to change their properties (like contracts, addresses and so on) authentication and authorisation is required. This is a specific attribute of the on-line channel.
The WebGateway can manage sessions with a on-line user and thus may provide services for authorisation and authentication. This can by combined with Identity management systems like Microsoft Active Directory, Crowd or LDAP.
More about this topic in future blogs.
Security is last on my list, but not on purpose. For IT departments and companies with a public exposure, this will always be a big issue.
I'll leave the firewall issues to the infrastructure experts, but the WebGateway may help by logging user activity or blocking users (for example by their ip-address).
The WebGateway may also use a technique called throttling to prevent misuse of Deniel of Service attacks.
If a company wants to create a public service, the SOA infrastructure could be a great platform for such a project.
In order to expose the existing SOA services to the internet, a couple of issues have to be addressed:
- Browser support
- Characteristics of on-line generated load
- Identity Management (authentication)
- Security (Authorisation)
These issues can be addressed by something I call a WebGateway.
Let me elaborate a bit on these issues.
The first and most import is support for browsers.
In order to reach a broad spectrum of users, all browsers should be able to use the exposed services. The 'old' way to do this is to expose the services using (D)HTML. A common way to do this is through a web application that generates HTML (like PHP, JSP, ASP, etc).
The downside of this is that the developer who creates the public service also determines the layout of this service (let's call this Web 1.0).
A new way to create public services is through REST style services, JSON or XML over HTTP.
This way, only the bare data is exposed, which enables frontend developers to use all their creativity to develop a slick and flashy website (let call this Web 2.0). Newly developed SOAP javascript libraries may give SOAP another chance on the internet.
The second issue is the load characteristics of on-line users in comparison to the way internal users are using the services.
The main difference is of course the number of users. For companies that offer public services (like telecom-, energy- and insurance companies) the on-line user base may be a 3-4th order bigger than the number of internal users (typical numbers for dutch companies are for B2B : 1000-10.000 and B2C : 10.000-2.000.000 users) .
In most cases where back-office system (mostly ERP or some kind of CRM/Customer Support system) are exposed by creating SOA services, the back-office systems are not designed for on-line use. Increasing the number of request by a factor 1000 or so may cripple the system and may render it unusable for the rest of the company (e.g. Customer Support).
This can be addressed by caching data in the WebGateway. The ways the cache can maintained will be discussed in a future blog.
The idea is that the WebGateway will try to serve as much data from its cache in order to decrease the load on the SOA services.
If customers are allowed to change their properties (like contracts, addresses and so on) authentication and authorisation is required. This is a specific attribute of the on-line channel.
The WebGateway can manage sessions with a on-line user and thus may provide services for authorisation and authentication. This can by combined with Identity management systems like Microsoft Active Directory, Crowd or LDAP.
More about this topic in future blogs.
Security is last on my list, but not on purpose. For IT departments and companies with a public exposure, this will always be a big issue.
I'll leave the firewall issues to the infrastructure experts, but the WebGateway may help by logging user activity or blocking users (for example by their ip-address).
The WebGateway may also use a technique called throttling to prevent misuse of Deniel of Service attacks.
Abonneren op:
Posts (Atom)
