Service Oriented Architecture

SOAP over HTTPS

2007-01-26T16:43:00.000-08:00

There are various mechanisms for securing the web services. Today, I will write about the scenario when a client needs to call a web service over HTTPS, provided the service is available over HTTPS.

This is Transport Layer Security (TLS) that runs beneath HTTP. Another is Message Level Security, which has many options (XML encryption etc) which is more secured.

This scenario is very common, though, it is not the perfect way of securing a web service, but it is used when, for example, a client is calling an authentication web service, by passing in the user id and password. Now, you don't want the password to go in clear text on HTTP, rather you would want this particular service be called over HTTPS.

Let's see how to make this happen. In theory, it is same as calling a URL in java using HTTPS.

First, go the the web service URL in your browser, using HTTPS and store its public certificate on your PC, in a file. This is done when the browser prompts the security warning about the server, view certificate and select copy to file, to save it on your local.

Once you have the server certificate, you need to store it in a keystore. I am using IBM HTTP Server, so I will use IKeyMan utility. However, this can be done using any corresponding utility provided by your HTTP server.

In IKeyMan, create a new JKS key store, select 'Signer Certificates' and click Add/Edit to add the saved server certificate to this keystore.

So, now we have the keystore containing the server's public certificate.

If your client is a Standalone Web Service client (meaning a stanalone java application), all you have to do is specify the location of this keystore using a java property before calling the web service over HTTPS.

Something like this, for IBM JRE:

System.setProperty("javax.net.ssl.trustStore","C:\\wsclient\\myWSClientKeystore.jks");
MyWSServiceProxy proxy = new MyWSServiceProxy();
boolean authenticatede = proxy.authenticate("john.doe@blogger.com");

Make sure the web service end point is using HTTPS.

Now, if you are using a Managed Web Service client, meaning one which is deployed in a EAR file (WAR or EJB), then you better import the server certificate in the keystore used by your application server or specify a new keystore in the application server.

Depending upon which application server you are using, the configuration options may be different. For example, IBM WebSphere has couple of options for doing this. A simple one is this:

Go to the WebSphere Admin console (I am using v5.1). Go to Security -> SSL. Here you will see SSL Configuration Repertoires. You can add cert in one of the existing keystores listed here, or add a new repertoire. When you add new, you can use the keystore we created above for standalone client. Please make sure 'Client Authentication' is not checked, as we are not doing the client authentication with the server.
Now, go to Web module -> -> Web Services: Client Security Bindings in the applications area, for you application. Under HTTP SSL Configuration, click Edit and enable SSL.

So, in this scenario, we did no authentication. However, with transport level security, there is also an option to do the authentication. Meaning, only the trusted clients can invoke a web service and get results.

In short, this can be achieved by generating a keypair (public key and private key) for the client. The keystore will contain server's public key certificate and client's public and private key.
The server will have to import the public key certificate of the client into its keystore. In this case, when a client calls the web service over HTTPS, the server will check if the request is coming from a trusted client, by decrypting the data using client's public key and its private key, and if decryption is successfull, will return the results.

SOAP carrying Attachments

2005-07-08T22:40:00.000-07:00

Well, it is very simple. I am using IBM WebSphere v5.1, and it uses Axis, so this should work well with Apache-Axis also.

Getting directly to the point:
A simple java class, which we will expose as a web service:
Method is:

public DataHandler getFileAttachment(String fileName) throws Exception
{
DataSource src = new FileDataSource(fileName);
DataHandler result = new DataHandler(src);
return result;
}

That's it. DataHandler, DataSource and FileDataSource are from javax.activation package.

Just expose this as a WebService and you are all set to receive files from a Web Service, as an attachment to the SOAP message.
A sincere advice, never use byte[] getFile() as a Web Service method, even for a small file, it takes so much time, transferring one byte at a time.

Enjoy!

Enterprise Service Bus

2005-01-26T16:44:00.000-08:00

Enterprise Service Bus or ESB is one of the most important components of Service Oriented Architecture (SOA). But what is it? Is it a product, a technology, a specification or a platform?

ESB is one or more of the following:

A distributed, heterogenous infrastructure
An event driven integrator
A message oriented integrator
An Intelligent router
A protocol transformer
A control point (for external services)
Able to substitute one service implementation with other, with no effect to client
A suitable level of quality of service provider
Provides means to manage services in SOA
Operate & integrate in an heterogenous environment

Basically, ESB is a logical architectural component, a set of infrastructure capabilities, provided and implemented by middleware technology, that enable the integration of services in an SOA. But, it is beyond just the routing and transport capability, at the same time not all of above capabilities are needed to have an ESB in place.

I would put the service choreography out of ESB. That is not really part of ESB, but some experts do keep it in ESB.
As you can see, ESB is suppossed to provide service routing capability, but not necessarily service directory. However, given that in scenarios like Web Services, UDDI acts as both service directory and router, therefore, make it also part of ESB.

We know that to implement SOA, both applications and infrastructure must support SOA principles. Enabling applications is the core - expose it as service, by creating service interfaces to the existing or new functions. Enabling infrastructure, at the minimum, involves the capability to route and transport service requests to the correct service provider. The role of ESB, in part, is to enable the infrastructure in this fashion.

That's the minimum, but what's the value add? The true value of the ESB concept is to enable the infrastructure for SOA in such a way that reflects the needs of today's enterprise.

I am much influenced by an IBM Redbook on SOA Patterns. So my views here are a reflection of what I read in that book.

The ESB supports multiple Integration paradigms:

The ESB must support in one infrastructure the three major styles of Enterprise Integration:

> Service-oriented architectures in which applications communicate through reusable services with well-defined, explicit interfaces. Service-oriented interactions leverage underlying messaging and event communication models.
> Message-driven architectures in which applications send messages through the ESB to receiving applications.
> Event-driven architectures in which applications generate and consume messages independently of one another.

The ESB does this while providing additional capabilities to mediate or transform service messages and interactions, enabling a wide variety of behaviors and supporting the various models of coupling interaction.

The ESB is positioned as an infrastructure component, and as such as a component that does not host or execute business logic. This is in contrast to components such as service requesters, service providers, and the Business Service Choreography whose role is to handle business logic.

Update: Many companies are now marketing ESB as a product or suite of products, so, no wonder if you see ESB products from different vendors competing. Well, you can commercialize anything nowadays.

Service Oriented Architecture - what ?

2005-01-17T17:05:00.000-08:00

Well, if you are in IT industry, you go anywhere - meeting, conference, online - all you find is talks about Service Oriented Architecture (SOA). While this term is old more than couple of years now, and IT Architects are still planning to design the systems based on services, a lot needs to be done to get to a real services based architecture which is also scalable and managable.

Basically, we know about Components Based Architecture. Every component provides some or other service, and if we take that idea little further, we will be living in a jungle of services and it will be hard to manage these services and any change in one service may need to modify other services, defeating one of the purposes of SOA.

So, we have to think and think hard before getting deep into these services. Creating a service, like a Web Service is no big deal, but getting that service into SOA model is more important.

Normally, what we do to get to SOA -

1. Create services, typically Web Services
2. Integrate services
3. Implement enterprise wide business functions using these integrated services
4. Deploy any new business processes/models using such services

And what are our main concerns, things come into our way:

1. Security
2. Access protocols & interoperability
3. Process flow
4. Workflow
5. Service availability
6. Contract (interface) change between service provider and consumer
7. Service implementation change
8. Service relocation
9. Service access through firewalls
10. Repeated Client side coding related to service access
11. Scalability
12. Performance

Those aware of Enterprise Service Bus (ESB) would think I am going to discuss that, and you are right. Well, ESB promise does fulfil many of these concerns, but ESB itself is quite open, and that is something we can start implementing and add things to it as we forsee issues.

Rest later......