Let's
quickly cover some basics so the blog makes more sense.
In
a classic academic SOA scenario, your organization is made up of bunch of
services. When you orchestrate them, you define their invocation sequence along
with some other information in an xml file, which follows WS-BPEL specifications. You then deploy the
process in a compliant process server. The server invokes the services turn by
turn applying other rules and logic (e.g. stop the process if outcome of a
service invocation is xyz) defined in the process.
In
a top down scenario, you model your business process as a WS-BPEL compliant
process, you define services that implement the tasks defined in the process, and
you deploy the process in a compliant process server, which invokes the
services to execute the tasks.
This
sounds simple on the surface but many architects don't realize that there is a
performance overhead involved in having a process call different services - the
overhead gets worse if the process is too fine grained.
As
can be seen from the figure above, the more 'boxes' you have, the more the
invocations from the process server to the services and the more the overhead.
When
I work with clients on SOA/BPM projects, I always encourage them to first
identify the business need to deploy something as a process. The high
level questions I ask are:
oDo you
want to collect runtime data on the process? If yes, what kind of data?
·Time take by the process or a task to
complete
·Revenue generated by a particular
activity
·Number of times a particular task was
performed
·Revenue generated out of a task or
frequency of revenue generated compared to the number of times a task was
performed
oDo you
need business flexibility when you can switch tasks around?
oDo you
already have existing IT systems but you just need a central coordinator?
Sometimes,
there are situations when there is a technical need to deploy something
as a process. If an organization has correctly implemented SOA, it would have
services that behave like black boxes, in which case you need a coordinator
that will do all the plumbing work. It may be a good idea in that case to
orchestrate services and deploy a process in a runtime. Some examples of
technical need are:
oYou need
to massage (map/transform) data between service invocations
oYou need
to implement some logic to invoke different services based on different
situations
It
may be possible to use an ESB to satisfy some of the technical needs but that's
another topic.
When
you do decide to deploy something as a process, an interesting exercise it to
determine the granularity of the process. Should you deploy every business task
as a task in the process or should you combine some tasks making the process
more granular? I will address this with an example some time in the future.
I fell in love with WebSphere mediations the first time I saw them. Okay, didn't fall in love but I did think... "Nice! What a cool way of going above and beyond what soap handlers offer!" For those who don't know, WebSphere mediations run in WAS runtime messaging engine, which treats any request or response flowing through as a message (could be a soap or jms message or even a request to an ejb) and any message consumer as a destination. Since we are [over] simplifying already, in simple terms WebSphere mediations are components that can intercept these messages, inspect them, route them to a different location or even change them.
Now, I wouldn't be writing this blog if everything about WebSphere mediations was so cool (yeah, I know, I have love hate relationship with IBM products!). Just note that the discussion in this blog entry refers to mediations available within WebSphere Application Server.
First of all, did you notice I call them WebSphere mediations? You won't see that term being used on any IBM website. I use that term because they use WebSphere specific APIs. You have to implement com.ibm.websphere.sib.mediation.handler.MediationHandler interface to create a mediation. This makes your code... well, not so portable. Mediations - woops, sorry - WebSphere mediations are very much like soap handlers. They can intercept the incoming requests and/or response and do things with it. There should have been some effort to make them part of the specification. I mean the whole concept of messaging engine is cool, even that should be part of the specification. The term 'messaging engine' doesn't refer to JMS messaging engine. It refers to the messaging infrastructure on which WAS runtime and service integration BUS are built.
Second, they only support one method public boolean handle (javax.xml.rpc.handler.MessageContext context) method. Why can't they support both handleRequest and handleResponse like soap handlers do? Being able to handle response would be really convenient. For example, if I had a requirements to process an incoming message and forward it to a queue for further processing ONLY IF the initial processing was successful, I would catch the response message in the handleResponse method and then send the message for further processing. Without the ability to capture responses, you have to be little bit creative to implement this requirement (you can still do it though).
Third, they use SDO APIs. This is not a problem in itself but I don't like IBM's implementation of this API. Just try creating a soap header within mediation if no header exists already and you will know what I am talking about. In plain English, I find IBM's implementation of SDO very 'read' friendly as opposed to 'read and manipulate' friendly. It is not easy to create/add new elements.
Forth, they can't be developed. Seriously! You cannot create mediations in RAD 7.0 - not even after installing some fixpacks. Now, I know this is not a problem with the mediations themselves, it's a problem with the tooling but hey I am in the mood to rant. To develop a mediation, you create an ejb project, create a class [say] MyMediation and implement the interface, go to ejb deployment descriptor and click Add button in Mediation Handlers tab. A dialog box should pop up and the class you created should show up in it. You select the class and the necessary ejb code is generated automatically. In RAD 7, nothing happens if you click the Add button. When I used Application Server Toolkit at my last client, the dialog box popped up but my class never showed up in it. I had to create mediation project in RAD 6 (yes, it works in the previous version!) and then open it in RAD 7. Nice way to take away some functionality!
Fifth, you can't register your service in the SDO repository - something you have to do when you have an outbound service that you want to mediate using mediation. I have blogged about this in detail in this and this blog entries.
Sixth, you can customize the behavior of your mediations using mediation properties - that's a good thing. But, you have to define and change these properties using admin console. This is not flexible, and boring too if you have many properties to define. It requires a technical resource to make a change - doesn't sound like providing business agility to me.
Note: The title is *Web services* infrastructural considerations as opposed to SOA infrastructural considerations. Designing SOA would take a lot more consideration, this article should give you a head start for services exposed as web services within your SOA
Of course you have to consider a lot of things when exposing a piece of functionality as a web service or as any service within soa for that matter. But today, I am going to focus on some system considerations only.
SQL attack
This problem is not specific to web services, this could occur even for any service implementation. SQL attack refers to the search criteria that result in a long running query (e.g. select *.* or select * from customer). It might be too late to implement a mechanism to detect a sql attack in the service implementation or persistence layer because by the time the service is invoked, the system may have unnecessarily parsed xml, logged the request, gone through a mediation, gone through some kind of transformation or even done a protocol switch.
Very large or hierarchical soap request
SOAP requests could get large - especially if the service allows any valid xml document to be embedded within the soap request. XML parser built into the web service container may perform poorly or even crash (especially when it is heavily loaded) if it has to parse a very large soap request. XML documents containing heavily convoluted hierarchies are also not recommended for the same reasons.
Large attachment
This is situation is similar to the one described above. A soap request with a large attachment increases the size of the message payload adding significant processing overhead and consuming a lot of bandwidth. Plus, parsing the separating out the attachment could become the bottleneck for the message flow within the system.
Repeated requests attempts
Some applications require the system to keep trying for certain time period or for several number of attempts if the first invocation fails. This especially happens in soap over jms environments. Such recurring attempts could slow down the service or could even bring down the server.
Too much reuse negatively impacting the SLAs
The soa approach often recommends implementing a business process by combining existing services. This means without a proper governance a service may be reused by many different clients negatively impacting the SLAs of the existing clients.
SOA infrastructure as the watchdog
A well conceived and well designed soa architecture provides infrastructure components to monitor and control the soa environment. Such monitoring may include:
inspecting soap requests for size and input parameters before delegating them to service providers
redirecting requests with heavy resource requirements to dedicated service provider
detecting failure and applying retry logic (e.g. retry only for certain types of failures)
routing requests to appropriate geographic location (e.g. routing eastern customer request to the East service center to take advantage of data processing within LAN)
and more...
It is possible to provide such infrastructural capabilities using various solutions such as ESB, soa monitoring systems (e.g. AmberPoint, Note: I have no ties with them) or even hardware (e.g. IBM DataPower - again, no ties here as well).
Products aside, when introducing soa in an organization, the architect must consider,
who is calling services
what is the volume, type and frequency of data exchange among the services
what SLA the services must support and how that resolves to the infrastructure requirements
where things could go wrong and how they must be handled
what are the routing requirements between service providers and service consumers
I provide no gaurantee or warantee (expressed or implied) about the code that comes with this blog entry; use it at your own risk. The attached zip file contains helloworld-ear.ear file and helloworld-client.zip file. The ear file contains ejb code in an ejb-jar file and http router code in a war file. Importing the ear file in RAD7 will automatically create necessary projects. The helloworld-client.zip file contains the client code to test the web service. You should be able to import the zip file as project interchange file in RAD7. If you have any questions, let me know.
Summary
I will be using WebSphere Application Server (WAS) v6.1 and Apache Directory Server (Apache DS) for this example. Also, to keep this article short and simple, I will not go into the details of how to create EJB, how to configure security, how to generate client etc. Instead, I have attached the code, which you can play with. If you need more details on the steps I have skipped, let me know. Here is the summary of the steps followed by more details:
Configure security on the server
Create an ejb, expose it as a web service and configure security on service endpoint interface
Generate http router servlet and configure http basic authentication
In WAS admin console, map the application roles to ldap group
Generate a web service client, set username and password and test
Configure security on the server
I have explained WAS and Apache DS security configuration in my blogs
Create an EJB, expose it as a web service and configure security on service endpoint interface
The bean class is available at helloworld-ear.ear\helloworld-ejb.jar\com\taraba\security\ejb\ :
package com.taraba.security.ejb;
public class HelloWorldBean implements javax.ejb.SessionBean { public String sayHello (String name){ System.out.println ("HelloWorldBean#sayHello() was called by " +name); System.out.println ("HelloWorldBean#sayHello() user: " +mySessionCtx.getCallerPrincipal().getName()); System.out.println("HelloWorldBean#sayHello() isCallerInRole: " +mySessionCtx.isCallerInRole("ValidUser")); return "Hello World " + name; }
private javax.ejb.SessionContext mySessionCtx; // other standard ejb methods avoided for simplicity
The sayHello() method prints a log statement, prints the username of the user calling the bean and whether the user is in ValidUser role. Finally, the method returns the string "Hello World" appended with the name supplied to the method. The EJB has already been exposed as a web service. Its WSDL file is available in the supplied ear file at helloworld-ear.ear\helloworld-ejb.jar\META-INF\wsdl\HelloWorld.wsdl.
Role based security configuration can be seen in helloworld-ear.ear\META-INF\application.xml
<security-role> <description> A user that can invoke methods on Hello World EJB</description> <role-name>ValidUser</role-name> </security-role>
And in helloworld-ear.ear\helloworld-ejb.jar\META-INF\ejb-jar.xml
... <security-role-ref> <role-name>ValidUser</role-name> <role-link>ValidUser</role-link> </security-role-ref> ... <assembly-descriptor> <security-role> <description> A user that can invoke methods on Hello World EJB</description> <role-name>ValidUser</role-name> </security-role> <method-permission> <role-name>ValidUser</role-name> <method> <ejb-name>HelloWorld</ejb-name> <method-intf>Remote</method-intf> <method-name>sayHello</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> <method> <ejb-name>HelloWorld</ejb-name> <method-intf>ServiceEndpoint</method-intf> <method-name>sayHello</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission> </assembly-descriptor>
The security configuration indicates that the sayHello() method of the EJB can only be invoked by the users in ValidUser role. This security configuration applies to remote and service clients (see the bold parts in the xml fragment shown above). Also review the security-role-ref section. This section is required since we are calling the isCallerInRole () method.
The security configuration described above is explained in ejb 2.x specification. Defining security configuration of sayHello() method exposed by the Service Endpoint Interface makes the method secure for web service clients. If the web service client is not in ValidUser role, as defined in the <method-permission> tag, UnauthorizedException will be thrown.
Generate http router servlet and configure HTTP BASIC authentication
The authentication configuration is configured in helloworld-ear.ear\helloworld-http-router.war\WEB-INF\web.xml
As the bold parts of the fragment above indicate, the /services/HelloWorld url is protected for ValidUser role. The users will be authenticated using BASIC authentication.
In WAS admin console, map the security roles to LDAP groups - so that the user information can be retrieved from LDAP
In configure security on the server section, I described how to create users and groups in LDAP. We will map the ValidUser role in the application to the endusers group in LDAP using WAS admin console as shown below:
Generate a web service client and set username and password
I generated a java client from the wsdl file and packaged it in a jar file helloworld-client.jar. I then wrote a com.taraba.security.ejb.client.HelloWorldClient class with a main method as shown below:
As shown above, the method simply instantiates the proxy, calls sayHello method on it and prints the result. Running the client as is will return a soap fault with Unauthorized error. To fix this, uncomment the following two lines in com.taraba.security.ejb.HelloWorldProxy#sayHello().
As you can see above, the usename and password can be set by populating USERNAME_PROPERTY and PASSWORD_PROPERTY defined in javax.xml.rpc.Stub class. If you are invoking the web service using Dynamic Invocation, you can set these properties in javax.xml.rpc.Call class. If you run the code after uncommenting those lines, you will see the following output,
HelloWorldBean#sayHello() was called by Taraba Consulting HelloWorldBean#sayHello() user: bob HelloWorldBean#sayHello() isCallerInRole: true
Recap
So, let's just recap what we did. We configured security on the ejb that was exposed as a web service requiring the client to be in ValidUser role. We configured security in the router servlet by protecting the url /services/HelloWorld - the url that would be used by the client to invoke the service. Again, we allowed only ValidUser to access the url. We mapped ValidUser role to the enduser group that I had already defined in LDAP. We set username and password of a user that belongs to enduser group in LDAP. Before you decide to use this method for web service authentication and authorization, I encourage you to review A word of caution section in my previous blog entry.
There is a simple way to authenticate a web service client - a way that often gets lost in the discussion of web service security standards, digital signatures, encryption and WS-Security. Now, WS-I only recognizes soap over http, which means soap messages are sent across the wire as http requests and responses. If you intercept a web service request or response using a monitor, you will see soap content inside the http header. For a soap over http request, we can use http basic authentication to authenticate the web service request. Form based authentication will not work here because the web service client cannot fill out a form.
The figure below show how this would work conceptually.
Figure1: Web service authentication using http basic authentication
Using servlet security to setup http basic authentication
For an ejb implementation of a web service, you have to put a servlet (or, theoretically, a jsp) in the front. Such a servlet (typically generated automatically) would listen to http requests and delegate the request to the ejb or java bean. You can configure http basic authentication on this servlet as shown in the code snippet of web.xml of the servlet (typically known as http router servlet in WebSphere world). The steps to make it work are outlined below:
Implement ejb and expose it as a web service (or generate ejb implementation from wsdl)
Configure security on ejb e.g. secure the web service method such that only users in a specified role could invoke that service. If the intent is to do both authentication and authorization, it is important to configure security on ejb
Generate the router servlet and configure http basic security in web.xml
Set the security credentials in the client code so that the credentials go with the soap request
Turn on the application security in your application server
Map roles defined in the application to a user or a group in a user registry
In the next installment, I will create a hello world ejb. The ejb will print the username and whether the user is in 'ValidUser' role, which we will define as part of the security configuration. I will also show how to set username and password in the web service client. I will use WebSphere Application Server V6.1, Apache Directory Server (as user registry) and RAD.
A word of caution
Before I end this discussion, I want to mention a few things. http basic authentication is not always the best way to implement web service security. This approach works only when the security requirements are simple and when the client is able to set the security credentials in http request. Not all clients are able to do so. As we will see in the next installment, a JAX-RPC client can do this by setting username and password properties on the javax.xml.rpc.Stub or javax.xml.rpc.Call. Also, by default, credentials set through http basic authentication are passed as a clear text within the http request - not safe when request comes from outside the network. When request comes from outside the network, https can be used. Finally, in this approach, the security credentials are NOT available in the soap message, they are available in http header. If your implementation requires processing of soap based on credentials, this approach will not work. In such a situation, you can use user token or ws-security.
I used this approach successfully for a web application that required authentication and authorization. The new requirements mandated exposing the ejbs as web services because some clients didn't want to use the UI we provided. Both client and service were written in Java.
