Fieldnotes from an SOA Technologist
andrerstmn 1200008W70 393 Visits
I haven't posted anything here in a long time, but plan to change that and make more frequent updates.
An article that I wrote just came out, called Planing and andling timeouts in service-oriented environments, which obviously deals with timeouts. I have this feeling - and have experienced it first hand - that many customers don't really pay any attention to this aspect. They typically leave all the timeout values at their defaults and don't think about the consequences a slowly responding system might have to their solution(s). And there are indeed many different places in which timeouts can be set, some of which are pretty well-hidden in the respective admin console. So one point of the article was to raise awareness to this issue, and encourage people to make timeout planning part of their overall deployment planning and add these things into SLAs.
The topic itself would certainly deserve a more thorough examination than what is provided in the article. Interestingly, I have not found anything on the Net that would dive into it. I could only find lots of references to the individual timeouts that can occur in IT systems, which hopefully makes my article a nice addition.
One of the core benefits of service orientation is the ability to quickly adapt a system to changing market and business requirements. In other words, my IT solution should be built in a way that shortens the lifecycle of any change that must be made. But is that really achievable with the technology we have available today?
One approach we take to reach this goal of more flexible systems is to raise the level of abstraction with which we define the implementation of an IT solution. One prime example for this is the use of a language like WS-BPEL and the WebSphere Integration Developer tool. We can create an automated business process by dragging and dropping logic elements on a canvas and visually 'program' the process implementation. Since this implementation is no longer coded in a traditional programming language, like Java, it should simpler and quicker to make changes, for example, by adding additional activities to the process, or by changing the sequence in which activities are invoked.
However, this still requires an IT-centric process to be executed: the required change must be communicated from the business to the IT owner of the process; the changed process must be tested, functionally and non-functionally; finally, it must be deployed into production. This basically takes it through the entire - and lengthy - lifecycle of a traditional IT solution. I have seen many companies where the establishment of SOA has not led to as much an acceleration in deploying new and changed solutions as was expected. I believe this leads to an evolutionary change in how we build these systems, especially in cases where frequent changes are required.
The idea is that we identify the 'points of dynamicity' in our solution (typically a business process) and raise the level of abstraction used to define these points even higher. At the same time, we want to make these points directly accessible to the business user, allowing for changes to be applied with minimal IT involvement. One example for this is the use of a Business Rule Management System, or BRMS. The parts of the process that involve any form of decision making can be delegated out of the (BPEL) process to the BRMS. How decisions are made is then handled entirely within that system and, most importantly, the rules that these decisions are based on can be entered and changed directly by business users! A system like ILOG's JRules even allows creating a "vocabulary" that maps technical information from the underlying runtime environment into terminology that is geared towards business users, including potentially natural language translation. Another example is a business event handling system like WebSphere Business Events, which can collect events from a large variety of sources and then allows defining the criteria for how certain sets of events trigger new business processes to be executed. This often complex correlation logic does not have to be implemented in Java or BPEL. And again, this can be defined by business users instead of involving IT.
All of these mechanisms are effectively targeted towards further closing the gap between business and IT, and give business users more power by letting them directly influence how the IT system works. I believe that we'll see much more of the same, i.e. trying to raise abstraction levels to make it easier to change service oriented systems.[Read More]
andrerstmn 1200008W70 880 Visits
Ever since I have been working in the web services space, I have had discussions about the service "style". That is, how do I craft a WSDL contract to make it easy to implement, easy to handle by the SOAP engine and interoperable between different vendor platforms. And even though it is not as much discussed anymore as it used to be, the subject still comes up every now and then. Today, we typically simply state that "wrapped document/literal" style should be applied for all Web services when possible. And usually I have pointed to a developerWorks article written by Russ Butek that gives an excellent explanation of the topic.
I just stumbled over a further - and formal, i.e. standardized - definition of this style in the JAX-WS specification. It defines a "Wrapper Style" and a "Non-wrapper Style". The wrapper style is defined with the following rules:
A WSDL operation qualifies for wrapper style mapping only if the following criteria are met:
This definition is exactly what we have been using before, so it simply confirms what we used as a best practice and turns it into a standard. The very last rule, saying that there cannot be any wildcards in the wrapper, is interesting. I have come across some examples where so-called extension elements were placed in there, using xsd:any, to preserve a place for future schema extensions. This rule basically requires that such extension elements be placed in yet another wrapper element. and that's probably a good idea anyway. (I have many more thoughts on the use of xsd:any in Web services contracts, but I'll save those for a future entry.)
As a result of this discussion, I decided that I need to do more with JAX-WS. It will quickly become the default way of developing Web services in Java, and this wrapper style is obviously just one out of many interesting and new (well, new to me who is still working predominantly with JAX-RPC)features that I want to explore.[Read More]
So this is my first entry in my new blog. Pretty exciting! :-)
You can read about the purpose of the blog in the title and abstract. It's all about making SOA work. And I don't want to get too hung up about the exact definition of SOA, or "what is a service", etc. There are other places on the Internet where these discussions take place. I want to explicitly use a very broad definition of SOA, namely as one that describes how we are creating software solutions today. And that's constantly evolving anyway.
Not long ago, I spent some time trying to find a good editor for WS-Policy documents. I find that many products, including some from IBM, support a more or less complete set of standard policy documents. But it becomes a bit more difficult if I want to create my own, custom WS-Policy document. One editor I found is part of the SOA Tools Project at Eclipse (see http://wiki.eclipse.org/Policy_Framework_in_STP). It is schema aware, which means that I can define my own policy language in a schema, and let the editor guide me when authoring documents. Unfortunately, I felt that this editor needs to grow up a bit more - it didn't like the schema I tried with it.
If you happen to know any other good policy editing tools, please let me know. Policies are a hot topic right now and I expect to see much more widespread use of them.[Read More]