Ali Pasha's WebLog... : Web Services

WCF Extensibility for Interoperability....

a_pasha — Fri, 17 Mar 2006 03:18:00 GMT

Jurgen's posted a great real world example of why WCF extensibility is essential for interop. The scenario he describes is that of having to a connect a TANDEM system written in COBOL to a Windows client using WCF. Which is an example of why you would...(read more)

How Actions differ from Operations...

a_pasha — Tue, 14 Mar 2006 02:48:00 GMT

I haven't thought about the relationship between “Actions” and "Operations" for quite a while. Therefore, I thought I'd give my brain dump. I look forward to your feedback in case I have it wrong. First, I thought it useful to summarize the description...(read more)

Contract-first Domain Specific Language (DSL)

a_pasha — Sat, 11 Mar 2006 07:59:00 GMT

Pedro was kind enough inform me about this cool DSL called "Contract-first" DSL: http://www.edwardbakker.nl/PermaLink,guid,0f4e80f7-2ebd-4ab4-a8b4-954cadfc622b.aspx I recommend that you take a look. I am eagerly waiting to play with this once is made...(read more)

Adding DataSets to services... Why not?

a_pasha — Thu, 09 Mar 2006 02:11:00 GMT

There a lot of customers, for better or worse, who are using DataSets in their services and (I shudder as I say this) there are times when it might make sense to do so. An example might be when the developer has control of both the client and the service provider, is working in .NET, and will continue to own both ends of the connection over time. The key advantage offered by Datasets are the features such as data bindings, validation, etc.

"You'd be amazed how many people don't care or use the 20,000 extra features in a dataset - we need a lighter weight object - but until I don't have that object, I'd much rather use a strongly typed dataset, than invent my own wheel." - http://codebetter.com/blogs/sahil.malik/archive/2005/01/23/47832.aspx

One comment I heard, that me think, was that if we (Microsoft) offered more tooling around DataContracts, etc. would people continue to use DataSets in their services?

This is the notion of little 's' services vs. big 'S' services that strictly follow SOA, as you're breaking a fundamental tenet by using (strongly typed) DataSets, i.e. you're sharing implementation not just shema and messages. With WCF I have to keep reminding myself that it is more than just Web services. As WCF has consolidated several messaging technologies, not just the various Web services stacks, there are scenarios that will be not very SOA-ish.

The challenge is facilitating the use of non-SOA recommended practices such as DataSets when it is appropriate, and making it difficult for users when it is not.

Lhotko's blog for why you should NOT use DataSets: http://www.lhotka.net/WeBlog/ThoughtsOnPassingDataSetObjectsViaWebServices.aspx

Ali

Operation inference and Contract-first Design

a_pasha — Mon, 06 Mar 2006 22:23:00 GMT

After Tomas's comment on my last blog, I've been thinking about the operation inference feature in Christian's WSCF tool.

I'm not sure that inferring operations based on the message name has been standardized. (Please correct me if I'm wrong) I've, nevertheless, noticed that several companies such as eBay name their messages in a standard manner similar to that used to infer operations by the WSCF tool.

My thoughts were that to do this right we would need to enable a wizard, similar to the "Text Import Wizard" in Excel, to import messages and create a contract. That way, a user could specify how to infer the operations based on message attributes and not be forced to name his messages in a particular manner.

Either way, I'm not sure that operation inference is a high priority. If we give users a manner to manually select the messages types/data types for a particular operation, we have made a huge leap. Automating the operation creation is simply a lower priority.

While this feature may be somewhat important to true message-first design, as users will claim that they should not have to think about operations, I'm not convinced that forcing users to name messages in a manner so that operation can be inferred is really that useful, unless, they were going to name their messages in that manner anyways.

Comments?

Thanks,

Ali

It's about the schema, stupid!

a_pasha — Sun, 05 Mar 2006 00:33:00 GMT

One of my big realizations has been that Contract-first is not about the WSDL it's about the schema. CWeyer's tool generates a WSDL, but the value of the tool is that it allows you to stich together the schema for the data/messages that you have created.

A lot of customers today spend most of their time developing the schema for their data/messages and never even see or edit the WSDL. They simply use the XSD to generate the serializable classes that correspond to the schema they have defined and then stich them together using ASMX, WCF, etc. The WSDL is simply generated for them at runtime. This is a lot simpler than creating a WSDL upfront with the XSD and then using it to generate the implementation. In my view, this is not WSDL first, but it is Schema first. It is, however, still Contract-first design.

The big question I keep asking myself is if they have better WSDL tooling would they create the WSDL first? Or are people really just asking for better tooling (read integration) around the serializable classes generated from the XSD?

Ali

Policy and Contract-first Design

a_pasha — Fri, 03 Mar 2006 20:31:00 GMT

After talking to a lot of people, I am trying to cement the relationship of policy to the contract. There is a thought that policy is part of the contract. That policy is created up front and negotiated between the two parties alongside the rest of the contract (i.e. WSDL).

Others have aligned themselves better with the four tenets of SOA. That the notion that "Services share schema and contract (not implementation)" is core to "Contract-first" development and that policy is negotiated between the services (perhaps afterwards) as stated by the fourth tenet, "Service compatibilitiy is negotiated through policies".

One comment I liked about policy was in the OASIS SOA RM spec is, "Whereas a policy is associated with the point of view of individual participants, a contract represents an agreement between two or more participants.".

Does this mean that the policy at some point may become part of the contract?

The way that I think about the problem is that there are several levels to Contract-first Design.

Level 1 - Functional

At this level, participants negotiate the functionality of the Web service. They describe the syntax of the interaction (schema&messages) and the semantics.

As WSDL is really just an IDL, today the semantics are described out of band in a non-standard manner, except in the few situations where the WSDL has been extended. One way is to use policy assertions to assert the business rules of service interaction.

Policy, however, has not really been used widely in this manner today. I would love to hear from you if you use policy in this way.

Level 2 - Non-Functional

Policy can also be used to assert non-functional aspects of a contract such as security, reliable messaging, transactions, etc. This is what most people in the industry think of when they think of policy.

While some think of this up front, I do not expect that this is as common as negotiating the form of the WSDL prior to implementation. Nor is it as asked for.

Thereore, to prioritize, I would definitely think that in the short-term WSDL first is what pops to mind when people say "Contract-first" development. In the long run, "Contract-first" will really incompass more than just the WSDL.

Comments?

Ali

Great quotes on Contract-driven (aka Contract-First) Development...

a_pasha — Thu, 02 Mar 2006 03:30:00 GMT

I was trying to get a pulse on Contract-driven Development and what the industry was saying, so I compiled a list of quotes and links.

As I think this might be useful for anyone interested in the area, I thought I'd share this out. Let me know what you think and if you have anything more to add about "Contract-driven" development that is not captured below.

I've also learnt that Christian Weyer recently published a new version of WSCF that works on VS2005. (http://blogs.msdn.com/smguest/archive/2006/02/27/540274.aspx).

Cheers,

Ali

Relevant Quote	Link
The trouble is this promotes a very code-first approach. This really sucks from a BizTalk developer's point of view. I already have my schemas. I know the shape of the messages I want to receive. Where's the support for the Schema- and WSDL-first approach?	http://geekswithblogs.net/dmillard/archive/2004/11/09/14651.aspx
If contract-first means wrestling with the nine-headed monstrosity known as Hydra, er, I mean, XSD, then it's doomed to failure...But the "everyone just wants to write classes" meme is WRONG (yes, I'm shouting) and the teams at Microsoft that believe it are doing a great disservice to their customers by crippling the toolset... I don’t know if they believe we (the great unwashed masses of programmers) are just too lazy, too stupid, or too ignorant to handle message-oriented programming, but they clearly don’t think we can handle it... I’ll believe Microsoft is serious about SO when the “Whitehorse” tools include a GUI facility for building messages (not classes!) and that tool generates schema and compileable code that can be tweaked by developers...	http://pluralsight.com/blogs/aaron/archive/2004/08/27/2092.aspx
Let's face it, big SOA / integration projects like Government, Inusrance, Pharma (the list goes on) starts with massive pre-defined schemas and large numbers of non MS systems. WSDL is defined based on those schemas and then a contract is implemented as client or server using .Net or whatever.	http://pluralsight.com/blogs/aaron/archive/2004/08/27/2092.aspx
Contract-First Development doesn't go far enough. The CBDI Forum advocates an extended version of Design by Contract, including Pre/Post Conditions, QoS and Commercial Contract ...	http://pluralsight.com/blogs/aaron/archive/2004/08/27/2092.aspx
I design my contracts using the built in XML and XML Schema editor's, but ultimately end up stiching the WSDL file together by hand.	http://blog.hackedbrain.com/archive/2004/08/31/163.aspx
Its this ability to have reusably defined types and easily assemble them into XML document definitions that we're looking for. Also, it would be great to have software that let you "harvest" the types present in XML document schemas and WSDLs to encourage type reuse, or for better searching amidst a sea of interface definitions.	http://blum.typepad.com/coarsegrained/2003/11/xml_schemas.html
Now, as a software developer, one's sole interest in contract-first development should be in defining the inputs and outputs of one’s software, and in ensuring that, if necessary, those inputs and outputs can be represented in a platform-independent format... The XML becomes a fetish, falsely imbued with the true virtues of contract-first development.	http://blogs.msdn.com/craigmcmurtry/archive/2006/02/01/522353.aspx
This morning I had the simplest class, marked Serializable, and ran it through an XmlSerializer test just to "be sure". Little booger started throwing those weirdo XmlSerializer exceptions. They are so hard to understand, even if you look at the InnerException, its enough to make you go stark, raving mad. Finally, I thought, "How about doing it backwards?" In other words, Let's write the XSD Schema and be happy with it. Then, we just fire up XSDObjectGen and let the tool generate the class, right? Well, it serialized perfectly right out of the box. I had gotten a property assignment wrong (mistakenly assigned to the public field instead of the private one in the ctor).	http://petesbloggerama.blogspot.com/2005/07/interesting-story-about-contract-first.html
Interface constraints or restrictions cannot be expressed exactly enough using programming languages. For example: "enumerations of concrete values" or "date vs time" etc. Interface very often contains only subset of the internal domain data, maybe even transformed, often restricted. A separate layer of mapping is usually anyway requred.	http://dev-blog.blogspot.com/2005/11/desing-web-services-contract-first.html
The problem here is WSDL itself: it’s an arcane, obtuse vocabulary that isn’t very human-readable. I don’t think it does a good job of describing web services in the same way that people actually think about them. The problem here is WSDL itself: it’s an arcane, obtuse vocabulary that isn’t very human-readable. I don’t think it does a good job of describing web services in the same way that people actually think about them	http://hyperthink.net/blog/PermaLink,guid,efd237dd-029b-4e51-91e4-711a8660c7c8.aspx
The insurance industry has two standards Origo and Accord. Both contain vast schemas detailing all the industry types and even message flows. Therefore the design of an SOA system will include message design and then the WSDL. The WSDL will define services based on these pre-defined types from these schema (such as a "policy" or a "customer" etc.). Once the WSDL has been built all the different parties involved can begin developing simultaneously against the contract in .Net or Java or KSH scripts and PERL if you like. If you tried to do this the other way around you'd be in a world of pain... minOccurs and maxOccurs just can't be represented using the code first approach. There's a huge impedance mismatch between .NET and Xml Schema.	http://pluralsight.com/blogs/aaron/archive/2004/11/11/3440.aspx
I previously expressed my preference for the term Design-by-Contract, since this term is strongly associated with a broader notion of Contract including preconditions and postconditions. Even traditional Design-by-Contract doesn't include some of the non-functional obligations expressed in a service contract, such as Service Level Agreements, Security Policy and Commercial Terms, which are essential for distributed computing and SOA.	http://www.users.globalnet.co.uk/~rxv/so/2004/12/contract-first.htm
WSDL is even more tragic. XSD’s ugliness mostly hides in the plumbing where civilians don’t have to go near it, but WSDL is in the customer’s face; as Nelson Minar of Google once told me, “The WSDL should be the .h file for my Web-services application.” Indeed, but WSDL as it stands is not something that wins friends and influences people. Even if it’s too late for WS-* to untwine itself from XSD, maybe there’s still a hope for finding a better way to publish service interfaces?	http://www.tbray.org/ongoing/When/200x/2004/10/21/Sells

Describing a reference model for SOA...

a_pasha — Wed, 22 Feb 2006 18:30:00 GMT

I got an email from Nichole last week about a talk that she was going to give on the OASIS Reference Model for SOA this Wednesday (tommorow) on the Microsoft campus.

See: http://www.iasahome.org/iasaweb/appmanager/home/chapterdetail?_nfpb=true&_pageLabel=chapterdetail_meetings&chapterdetail_meeting_portletid=15401&chapterdetail_meeting_portletchannel=3216

As this was the first time that I had heard of the reference model, I decided to read through it. Fortunately, I found nothing too surprising or new. The following comment, however, made me really think:

...the terms "loose couplising" and "coarse-grained" are commonly applied as SOA concepts, but these terms have intentionally not been used in the current discussion because they are subjective trade-offs and without useful metrics. In terms of needs and capabilities, granularity and coarseness are usually relative to detail for the level of the problem being addressed, e.g. one that is more strategic vs. one down to the algorithm level, and defining the optimum level is not amenable to counting the number of interfaces or the number of types of information excanges connected to an interface ...

Initially, I was suprised that "loose coupling" and "coarse-grained" were not part of the reference model. After rereading the paragraph and giving it some thought, I have come to agree with the RM. What are your thoughts?

See the following link for more information: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

Ali

WSDL Namespaces

a_pasha — Tue, 23 Aug 2005 23:00:00 GMT

In creating demos, I always need to make sure that we have a realistic scenario. With regards to that, we try to be particular about the namespace that we choose for the varoius WSDL elements. This post documents what guidance I have read and recieved.

In an old article by Scott Seely he mentions, "Each component will have its own targetNamespace with a common root URI".

When I asked Aaron Skonnard what this root should be he gave the following guidance, "Typically it is a heuristic". He then mentioned that several companies use the following convention in asmx:

* http://domain/company/division/name_that_describes_what_the_namespace_defines.

W3C typically also puts in the Year. Some companies also use the namespace for versioning.

So thinking thruogh this, I came up with the following example:

* http://msdn.microsoft.com/visualstudio/samples/2005/09/24

An example of the service namespace might then be:

* http://msdn.microsoft.com/visualstudio/samples/2005/09/24/WebService

When selecting the binding namespace we might want to add the protocol that is supported by the binding. This is particularly useful if multiple bindings with multiple protocols are supported.

* http://msdn.microsoft.com/visualstudio/samples/2005/09/24/WebService/soap12

Schema types should be in a different namespace as the types can be shared. An example:

* http://msdn.microsoft.com/visualstudio/samples/2005/09/24/types

New Web services category...

a_pasha — Tue, 23 Aug 2005 22:53:00 GMT

Our group's speciality/expertize is to build Enterprise tools. However, we do this with collaboration with several other groups whose expertize may be in a particular domain.

I hope to use this category to publish what I have learnt from the Indigo/WSE/ASMX teams and other people in the industry w.r.t. to Web services design. This is because I think this information will be useful to those who use our tools. Furthermore, it will help give insight into why we made particular design decisions.