Fine Grained vs Coarse Grained BPEL

At a customer this past week, the team was examining the WSDL that had been defined for a new project. The WSDL was broken into three definitions but was going to provide aggregation capabilities for a single consumer. Since the consumer portion was already under development, there was a strong desire to limit the number of changes made to the interfaces. The first discussion was whether to use the several interfaces as separate services or to boil them down into one interface. If this was done, do we just map the current operations onto the WSDL interface or do we replace them. The current services were pretty fine grained providing specific capabilities for search. The results returned were represented as different elements with no consistency. Two options were then explored:

1) Create a single WSDL that had N number of operations matching the current operations that were currently spread across several WSDL.

2) Blow up the WSDLs and start from scratch creating a coarse grained interface that provided a single search operation. For the Web Service implementation, it would need to examine the query data to determine which type of search was being requested or a new element with an enumeration of search types could be added.

In both cases, revisiting the schema and collapsing the numerous elements that existed previously into a query input and search result was agreed upon.

To demonstrate the impact of solution 1 or 2, we then turned to BPEL and developed the service implementation as a BPEL Service. Why BPEL, well this service was meant to aggregate data from various sources depending on the input.

If we examine solution 1, the WSDL would have 8 operations. One option to support this was the use of a the Pick Activity and OnMessage Activity. One OnMessage per operation could be employed creating processing pipe creating an Event Driven design.

If we examine solution 2, the WSDL would have a single operation and thus would support a more traditional Receive/Reply Activity.

So in essence, the use of a Fine Grained WSDL impacted/reduced the options for BPEL development, whereas Coarse Grained WSDL did not.

Simplification via the Service Interface

I was recently working with a client who had developed a solid demonstration vehicle showing many moving parts. As I was working with them, we identified that the service interfaces were developed with varying degrees of granularity. The data granularity for some of the interfaces was fine grained expecting small sets of data whereas other expected a full document or were coarse grained.

To simplify the demonstration and complete the round-tripping exercise they were shooting for, we standardized the WSDL definitions to use the same Schema and to push the entire document across the wire between the services. In essence we standardized on a coarse definition. This then untethered the controller service they had defined in BPEL to just copy the top level element between services.

As changes occurred in the demo, the refactoring demonstrated that maintenance or updates were much simpler or non-existent.

From a business perspective using the business documents in the interfaces provides a SOA centric approach towards development. This approach doesn't always make sense as with very large documents, there may technology or complexity reasons to limit the use of such an approach. In those cases fine grained access make sense albeit with more work on the orchestration side.

Thomas Erl SOA Training

Last week I was able to participate in training provided by Thomas Erl and his SOA Systems consulting organization. Being a fan of his books and how they crystallize the SOA concepts and associate them to the Web Services Standards, I was very excited to participate. Unfortunately I was only able to partake in 2 of the 4 days. These days focused on the SOA Methodology he has been working on namely SOA Modeling, SOA Analysis and the beginnings of SOA Design.

Through his various books such as SOA Principles of Service Design and Service-Oriented Architecture a process of examining a current business process was defined. During the process, services are logically grouped into task, entity and utility. Each of these denotes a certain level of capability or interaction. The Modeling/Analysis phases help identify which bucket they belong in and confirm they follow his 8 SOA Principals such as Autonomy, Stateleness etc.

What did I get out of the session? Simply put a methodology that allowed the team I was working with to break a current process into its core services and model the message exchanges that would occur if implemented. This was done at a high level but demonstrated a simple approach that allowed both developers and a business analyst to communicate effectively.

Operations is my customer

So I got a chance to partake in a Franklin Covey Leadership Training exercise several weeks ago. I was not sure what I would take out of the training and whether it would be beneficial. I was extremely impressed by its content, focus and most importantly the instructor. Long story short the class tried to identify what is a leader and how to become an effective one. As part of the sessions a discussion around identifying your customer came up. For the current customer I am working for, it is a little interesting in that with middleware there are many customers. Specifically though once in production, operations becomes a major customer.

What I learned is that to make an effective middleware platform, quality comes in the flavors of Reliability, Scalability, Manageability. When these quality attributes skip a beat or fail to occur, Operations has to swoop into action. The benefit of the training underscored the need for me to develop simpler and more capable tools to handle customer issues. Additionally, the increasing complexity of our SOA has begun to exacerbate the monitoring and management once in production. Log4J logs, JMX and Management Services become the virtual console for operations and development.

While these solutions may not occur immediately, I am working with them to define best practices, provide training and eventually automate solutions. This has resulted in reduced operational issues as well as increased self-reliance. Most importantly, this process never ends and must continue to be executed to provide consistency of results.

SOA Training, what is it?

Based on my current role as an independent consultant I have run into several clients looking to develop SOA technical skills inside the organization. Due to my Web Services lineage, I of course look at the SOA solution set via the W3C and OASIS toolbox. From a training perspective I highly recommend the Cape Clear Developer site for two training facilities:

1) XML Schema / SOAP/ WSDL

Check out  http://developer.capeclear.com/?q=justenough

2) BPEL

Check out http://developer.capeclear.com/?q=bpeltraining

I am looking for some decent tutorials on XSLT/XPath. Currently I have been using the www.w3c.org and O'Reilly. If you have any suggestions on alternative tutorials/locations let me know. 

3) SOA Specific Articles / Books

Thomas Erl and his series of publications are a must. http://www.soamagazine.com and http://www.soabooks.com

Finally although not specifically for SOA but rather all the other technologies like  AJAX, OOAD, HTML etc the Head First series from O'Reilly is excellent.  

To Spring or not to Spring

I am trying to get a sense from people as to which framework people are selecting, Spring or EE5. Several different projects I am privy to at different companies have employed Spring with good success. Another colleague just published a book on JBoss SEAM with its EE5 underpinnings and is very high on its capabilities. Long story short it seems like this is going to be a Ford versus Chevy debate. Maybe I am wrong but would love to hear any feedback. 

Due to the use of Spring configuration and Spring Bean support in Cape Clear 7.5, I see my path has been pre-determined. 

The Web Service Standards Soup / BigSOAGrid.com

Over the past several weeks, a former colleague and I have put together a grid of the current Web Service Standards starting with the core and extending to the WS* features. You can find this at:

http://www.soamag.com/I11/1007-1.asp

or at its home:

http://www.bigsoagrid.com

The purpose of this is to highlight the many options / directions the standards have gone as well as the large amount of vendor participation in these specifications. Obviously having vendors write standards is a double edged sword as they most often will have an offering following the standard release and will be pushing it on you and I. With the open source movement however, you will find a bunch of these standards available in Apache projects, Codehaus etc and the time/effort spent by other technologists can save time for us all.

One example of this was a project I worked on recently for a State Government contractor. There was a need to support basic authentication and integrate this with LDAP. Within a half an hour discussion, the decision was made to use WS-Security UsernameToken. The implementation took advantage of the WSSJ package from Apache and in a few hours this feature was ready to test. The alternative might have been a custom SOAP Header and the resulting WSDL / Interceptor work to build out the infrastructure. Not worth it when deadlines are tight!

So take a look at the BigSOAGrid and get up to speed on the latest and greatest. Maybe you will find a standards based option for your project needs!