This is a topic that comes up quite often when talking to clients. Based on some of the successful implementations that I have been lucky to be involved in, the one demoninator is how important XML Schema is in that success. In addition the existence of a Schema Custodian (Thomas Erl term) or a individual who guards the Schema with his/her life. The more difficult a Schema is to change, the more likely that it will succeed in an enterprise SOA. Sounds kind of strange but the foundational aspect of XML Schema in its use in WSDL, BPEL, XSLT, XPath/XQuery, auto-generated skeletons/stubs.... means that minor changes could seriously impact a deployment.
One of the clients I work with has successfully employed a XML Schema definition for 3+ years now. The schemas have been allowed to evolve via the use of optional elements but those evolutions have been through a small group of Schema Owners and it is not modifyable via the developer community. Because of the inherent difficulty in changing the schema, it has prevented Schema creep and the potential interoperability damage quick changes could cause. The benefit of this has been interoperability across a wide range of technologies starting with four different app containers and two different JMS providers.
One other area of discussion is on versioning of Schemas/Services. One approach that I have seen is the use of the namespace and ESB technology to route based on unique namespaces. Namespace versioning can be something like:
http://www.mycompany.com/2007/12/ProvisioningService
This service would then have been developed in December 2007. People are familiar with this approach with some of the WS-* standards like WS-RM. The good part of this is that for me to invoke a service using this as the target namespace, requires that my SOAP Request call it out. The bad news is that changing this will break any clients that were developed against it. A quick solution is to support several services if the namespace changes by infrastructure like an ESB and XPath Routing. A simple XPath statement focusing on the SOAP Envelope could route this request to the correct destination. There are several other versioning solutions, check out developer.capeclear.com for a whitepaper on Service Versioning.
Wednesday, December 19, 2007
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.
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.
Monday, December 10, 2007
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.
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.
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.
Wednesday, November 7, 2007
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
2) BPEL
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.
Subscribe to:
Posts (Atom)
