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.
Subscribe to:
Posts (Atom)
