|
|
| Service Oriented Enterprise |
|
|
Saturday, November 01, 2003 Publishing SOAP Calls WSDL doesn't completely suck. But it isn't the friendliest vehicle for giving a person access to some piece of information. Let's get real. WSDL as it exists today was largely designed by distributed computing gurus who have added the art of aspect oriented programming to the art of IDL design, while plopping it all on top of our latest markup language, XML. The Interface Now, one thing that I do like about WSDL is that I can define the contract (or interface) without specifying an implementer (the binding / port). This allows me to head down the 'contract-first' design path. It also allows me to create a service contract and easily share it with other people. Interfaces with aspect oriented, or declarative resolution of non-functional requirements are pretty damn cool too. Well done. The Service A service is created by binding an interface to an implementation (i.e., listen for the call on port 80, with HTTP...). Thus, a service not only specifies the contract (Types, Messages, PortTypes, Operations & Fault), but one that also specifies the aforementioned deployment considerations (Service, Port, Binding). Design Time: When you are designing your functional solution, you knock your contracts (interfaces). Deployment Time: When you are designing your non-functional solution (scalability, availability), you knock out your services. Publish Time: Now, an interesting question arises when I want to publish my contract and its binding for others to consume. As developers, we tend to think that of sticking a pointer to the WSDL in the UBR or shoving it into Xmethods. Nothing wrong with this, as long as you realize that WSDL isn't easy to consume and that it is very likely that someone will give it a shot and eventually give up because the WSDL didn't give enough information to actually be used for its intended purpose. For that matter, they may just look at the 25 different operations specified in the Port Type and realize that they don't even know which operation to call. Calls This leads me to Calls. A Call is an instance of an invocation to a Service. Put another way; it is the SOAP envelope all filled out. In many cases, this is what people really want. Consider this: what if instead of publishing my WSDL (with many operations), I merely publish a single operation with many of the parameters all filled out (default values). Now, instead of exposing a WSDL that has a PortType holding 25 different operations to my Calendar Server, I simply publish a SOAP document that performs a call: What: CalendarAgendaRequest Who: Jeff Schneider How: Use the SOAP format and send it to WS-Addressing( location XYZ) Prior to the WS-* specs, publishing a call didn't do any good. The calls were self-contained (contractually), but were not self-contained from a service perspective (binding). That has all changed. This means that for the first time, we can pre-populate SOAP calls, save them off and make them available to our end users. This is a HUGE leap forward in usability. Now, developers will have two options: 1. Create a WSDL will all operations and combinations (for power developers) and 2. Create a SOAP message, partially pre-populated (for business users). Now, in order for this to work, it means that we have to quit writing applications that only suck in WSDL's (like InfoPath, Excel, etc.). In addition, you will have the option to pass in a URL to the SOAP envelope (AKA, SOAP Poiner). Again, the reason for publishing a call is to make it EASY for a non-developer to gain access to some operation. posted by jeff | 9:20 AM Monday, October 27, 2003 Indigo documentation I finally found some documentation on Indigo: http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx posted by jeff | 5:33 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
