Don Smith : Service Factory

Updating the factories to VS2010

donsmith — Fri, 06 Nov 2009 00:10:00 GMT

This is just a quick post to let you know that I just posted an update over on the p&p team blog. Since this effort spans GAT/GAX and 3 factories, it makes more sense to post the updates there instead of here. Sorry for any confusion. Feel free to ping me if you have any questions. I'll still be blogging here (hopefully more) just not about the factory refresh project. Thanks.

Using MessageContracts and DataContracts

donsmith — Tue, 11 Mar 2008 05:10:00 GMT

Users of the Service Factory often ask about the rationale behind the required use of MessageContracts even though the use of MessageContracts aren't mandated by WCF. I've answered this question in other venues, but it seemed like a good thing to put here in case I need to point others to it in the future.

If you ask the WCF product team when you should use a MessageContract versus a DataContract, their guidance usually revolves around the level of control you need over the message - like when you need to use custom SOAP headers*. You can find more detail in this topic of the WCF documentation. Their guidance makes complete sense if you think about the motivation they had when building WCF: to unify all of the Microsoft communication mechanisms into a single approach that is relevant to all scenarios. This is great for someone who has traditionally only done object-oriented or component-oriented development. They can be successful without understanding the nuances of building Web services.

In our experience one of the biggest hurdles for many developers who are new to Web services has been the concept of the message - rather than just passing around types like they've always done. You can characterize this distinction as implicit versus explicit message design. We have a topic in the Service Factory documentation that touches on this distinction. I think there is some room for improvement on this topic, but you can find it here nevertheless.

However, the confusion over a message isn't the only reason we elevate the importance of the message and recommend these usage patterns. We intentionally draw a clear distinction between types (both primitive types like string, and complex types like Customer) and messages (like ProcessExpenseReportRequest). From our perspective, DataContracts represent types and types are reusable. Messages are not used as types but rather the payload a method operates on - and it is not reusable since they are specific to the operation they are passed to and from. This level of distinction provides architects and lead developers a means of achieving better consistency throughout their organization by being more prescriptive about reusability.

I am aware that Juval's position is that MessageContracts are rarely needed. And, I hold Juval in the highest regard - I've not yet had an opportunity to learn what is motivating him to take this position. Some might argue that MessageContracts are just an additional (unnecessary) level of redirection. I can understand this point of view. We just feel the benefits greatly outweigh this nominal cost, and the feedback we've received from customers has been completely supportive of this approach.

* In my opinion, there is only one reason you would need to create a custom SOAP header that isn't already defined by a standards body like WS-*. (hint: if it's already defined elsewhere, you should use it to ensure interoperability, instead of "rolling your own") And, that reason is if you need to pass around localization information (like "en-us"). I don't think this is covered by any WS-* or other spec.

A time for reflection and assessment

donsmith — Tue, 08 May 2007 09:15:00 GMT

Wow, it's hard to believe it has been almost a year since the patterns & practices team released our first software factories. Remember when the early customer previews were called Baseline Architecture Toolkits? Oh, the nostalgia :) We could have had so much fun with the BAT acronym ... haha.

So that means now is a perfect time to take a quick assessment on how we're doing so far ... that's right, a survey. Now hold on a second! At least hear me out for the rest of the paragraph. I can't devulge too much detail yet, but some team in Microsoft might be in the middle of building some serious software factory infrastructure for a future version of Visual Studio - that's right, much better than GAX and DSL tools. Do you want it to suck? Do you think software factories are just a pipe dream and would rather they build something else? If you're thinking, "Oh no Don, I like software factories, especially the Service Factory (okay, I'm embellishing - haha)," then I would ask you to keep reading. I promise we've tried to optimize the survey to allow you the highest level of impact in the least amount of time possible.

Whew, you're still reading ... excellent! Okay, so you're only looking at 9 generic questions and 9 questions for each software factory you've evaluated/used. This survey covers the 4 factories released by p&p (web service, smart client, web client, and mobile client). The first 8 questions will take no more than a minute or two. The 9 questions for each factory shouldn't take more than 10 minutes each and you will only see the questions for the factories you choose. The last question is an anything-else-you-want-to-share question - you can take as long as you want on it. That's it ... super quick-n-easy.

Here is the URL you need to take the survey: http://www.zoomerang.com/survey.zgi?p=WEB2266YYVWSKP

We're really looking forward to your feedback so we can help the future include some truly kick-ass factories.

First Service Factory v3 Community Drop

donsmith — Sat, 07 Apr 2007 09:28:00 GMT

Okay, we're off and running now. Earlier today I posted the first of many community drops for Service Factory v3 - don't let "build 19" fool you - this is the first one. It took us longer than expected to get this one out the door, but we're all set now.

I suspect the first question you have is "What is so specially about this release?" Fair enough question. Well, probably the biggest thing is the addition of models. This alone accounts for most of the improvements over v2. I'm not going to go into too much detail here (there will be plenty of time for that later), but here are the high points:

Now Visual Studio has a memory about your decisions. In v2 you place your decisions in wizards. In addition to models, there are still wizards, but it's the model that "remembers" so you can generate code anytime you like.
Now you have a visualization of the application you are building. The designers provide this. Right now there are 2 designers/models. The first screen shot below shows the one for service contracts and the one after that shows data contracts.
Now you can delay the platform decision (WCF/ASMX/etc) and the language decision (C#/VB/etc) until as late as you like (way after you define all the service, message, and data interfaces.
With this version there is also no assumption that you have already define the service contract before you start using the factory. You can either approach the solution from a capability perspective (dropping operations on the service contract designer) or from a data perspective (dropping data contracts on its designer).

Here is what they look like (I added the thin red boxes):

I'm trying something new during this release by including a "start here" document and a "walkthrough" document for each drop. I'm hoping this will:

Save you lots of time in evaluating this drop.
Set your expectations around how much time you will need to evaluate the drops.
Provide you a very directed way to provide feedback about the drop.
Give you an easy way to see what the new features are every 2 weeks.
Let you know what the known issues are with each drop.
Get me more high quality feedback so I'll know we're building the best, most appropriate Service Factory we can for you.

So please use these docments and give me your thoughts about them.

You can expect new community drop every other Friday until the end of October (unless something really unexpected happens of course).

Download Service Factory v3 Community Drop 19 here

Looking forward to your feedback ...

Now Available: Aaron's new Service Factory article on MSDN

donsmith — Thu, 11 Jan 2007 11:04:00 GMT

Steven just told me that Aaron Skonnard's latest Service Factory article about the December release was just published through his Service Station column in the MSDN Magazine. Talk about timing ... sweet.

Even though it was written and finished before we locked down the code, it is still very accurate and comprehensive. I mean, it's Aaron ... what else would you expect?! There a few minor places where we changed the code out from under him so if you have a question about anything in it, feel free to leave a comment here and I'll field it.

Oh, and if you're building ASMX services, be sure to check out his first Service Factory article about the July (ASMX) release.

Great job Aaron!

... come and get yer Service Factory!

donsmith — Wed, 10 Jan 2007 07:30:00 GMT

That's right ladies and gentlemen, the December release of the Web Service Software Factory and a VB.NET version is now available for your consumption, modification, and production pleasures :)

Okay, I'm just going to do 3 things in this post since I know there will be many more to follow:

Lay some links on ya. For downloading the Service Factory releases and more info.
Share my favorite new features of the Service Factory with you.
Give you a sense of what is to come in the near and not-so-near future.

Links

Service Factory December release helps you build both WCF and ASMX services in C#. The old July release is no longer available since everything it contained is included in this release. Web Service Software Factory–December 2006 (ASP.NET and WCF services in C#)
Service Factory July release that helps you build ASMX services in VB.NET. Yes, I know this is new and was actually published in December, but it is effectively the same exact version as the original July release - it's just been converted to VB.NET (that's why we're calling it the July release). If this is confusing, I apologize ... I'm to blame. Web Service Software Factory–July 2006 (ASP.NET services in VB.NET)
Service Factory information. If you're not sure what the Service Factory is and want to find out before downloading it, go to http://msdn.com/servicefactory to learn more about it.

Favs

WSDL-first support. This feature definitely wasn't the most challenging to include, but I still love it. I've spent a lot of time over the years monkeying around with WSDL files. The fact that Service Factory has a single recipe (wizard) that will take a single WSDL and generate the service interface, service implementation, binding configuration (config file), and all of the associated DataContracts/XmlSerializable types is just freakin' sweet. You have to see it even if you don't define all your contracts in WSDL first.

Versioning guidance. This is a favorite of mine because ... well, I wrote it haha. No, seriously ... it's no secret this is a topic that is near and dear to my heart. I have labeled the topic "emerging guidance" in the Service Factory documentation because I want to gather more evidence from customers that this approach is actually working for them before I propose we call it a "proven practice". I have spoken with a number of customers who have taken this approach and it is working well for them. I haven't spoken to anyone it didn't work for, but I'd love to hear from you. If you're interested in reading or sharing, I've also posted the topic on my blog here. Personally, I think the "strategy" section of the guidance is still weak on content, but more on that in the "futures" section of this post. I also plan to do a webcast on it.

WCF Code analysis. This one turned out to be the sleeper feature - we didn't expect this to turn out so sweet. As you may know, FxCop has been integrated into Visual Studio 2005 under the name Code Analysis. Well, we took all of the same rules that used to be the Security Analyzer back in the WSE days and converted them all to code analysis rules. They also work against the code AND the config files (something FxCop hasn't done historically). I know, pretty sweet, huh? Well, when we showed this to the WCF team, they asked if we could include some of the rules that they fire at run-time so they could be run at design-time (like the ones that make sure all the binding stuff is consistent). "Sure", we said. So there are about a dozen of them too ... and it's all integrated into Visual Studio ... even if you're not using Service Factory.

Recipe runner. Okay, now I'm cheating a little. This isn't actually a feature ... and it's not really included in Service Factory. One thing we learned while building the July release was that testing GAX recipes is feakin' hard. Well, harder than it should be. So the team took a couple of months at the beginning of this version to get it right. The result is something we call RecipeRunner. Those of you who are creating your own recipes or heavily modifying the ones we provide will really like this if you care about testing, which you should. We'll be making it available on the community site in the near future.

There are loads more things that are new and way cool in this release, but I want you to discover some of them for yourself too. Of course I'll be mentioning them as time goes on and in some mini videos. Oh, that brings me to the last item on my agenda.

Futures

Blogcasts. The very next things you're going to start seeing are more of the blogcasts I did some months back. Many of them are outdated now and I need to do more of them now that the WCF Service Factory has released. The feedback was very positive (thank you) and because I claim to listen to you, I promise to do more of them shortly.

HOL exercises. I've already began the process of converting the existing hands-on lab (HOL) to WCF. Additionally, we'll be adding a bunch of new exercises. What I need from you is some details so we're sure they are helpful. This is what we have in mind:

Modifying a guidance package - There is already a how-to in the Service Factory documentation, but customers are always telling me they need more help. If you tell me what kind of changes you're making to guidance packages I will try to create an exercise that illustrates how to make that change.
Building a service agent - A service agent is that layer of code on the consumer side that invokes the proxy (that's right, you're NOT suppose to do it in the button's click event handler :). It manages things like retries, response caching, offline support, asynchronicity, etc. I need you to tell me what kind of challenges YOU (not your neighbor) need. That will help me get this exercise right.
Versioning - this will build on the topic I mentioned earlier and will walk you through how to evolve a service in a number of ways.
Message validation - The reference implementation already illustrates this. But would you find a HOL exercise valuable? If not, cool, I'll spend that energy somewhere else. If so, also cool.
Exception shielding - The reference implementation also illustrates this. Same question ...
Create a code analysis rule - I think this is also covered in the VS documentation, but I've never looked for it. Are you going to be writing your own rules? If so, would you find a HOL exercise helpful?
Workflow Foundation - we actually did a lot of work with this, but had to pull it at the last minute (yeah, sometimes cutting scope at the last minute hurts). We might be in a position to create an exercise as a result of what we already have. We'll see.

v3 planning. We have already began the planning process for v3. But because we JUST started, we don't have a lot to share just yet. I can tell you (if you didn't already guess) that a service domain specific language (DSL) is the primary theme of the next version. I will be sharing everything with you around the features and their priorities as soon as we have something to share. As always, we'll be counting on you to steer us where you need us to go. All of this communication will naturally happen on the Service Factory community site, which will be moving to CodePlex in the very near future. More on that later too.

Okay, it's getting late and the weather is getting nasty so I'm heading home. Until next time, you have a lot to keep you busy :D Looking forward to your feedback. Thanks!

Handcrafting WCF-friendly WSDLs

donsmith — Fri, 06 Oct 2006 10:30:00 GMT

It's 10:15 pm and I'm still in the office, but I really think I should get this entry posted before I head home - or it won't ever get posted. I was supposed to be working on my demo for my Service Factory session at the SOA Conference tomorrow, but I got side-tracked early in the day when I started playing with a new feature of Service Factory (that I'm going to demo). This new recipe (hereforth referred to as "the new recipe") allows you to create the service interface, data contracts, and a stub of the service implementation from an existing WSDL document. Yeah, pretty cool, huh? Of course you can do the same thing in svcutil if you have the .NET 3.0 SDK installed, but you have to leave Visual Studio and head off to the command prompt - and it won't separate the parts into multiple files and place them in the appropriate projects.

As I'm sure you've already realized, we've added this feature for the masses who have adopted a contract-first approach to building services. Unfortunately for these masses, the object model you have to code against after you've generated code from your existing WSDLs (using either svcutil or the new recipe) is not as enjoyable as what you get with the code-first approach WCF and its DataContract offer. I'm hoping this entry will add some clarity for those of you who wish to have the best of both worlds: Contract-First and DataContracts. First, let's talk about the DataContract.

The DataContract

Rather than start from ground zero with DataContract basics and the DataContractSerializer, I'm going to recommend you go read Aaron Skonnard's excellent Service Station article on Serialization in WCF before continuing. Okay, now that you know DataContract only supports a subset of XML Schema, let's get more specific about this "subset". I am in no way stating that this is a complete list, but these are the things I've personally been able to verify. If you use any of the following constructs, svcutil and the new recipe will fall back to creating XML serializable types (like the ones in ASMX) instead of DataContracts.

<xs:element ref= ...
<xs:anyAttribute ...
<xs:group ref= ...
<xs:attribute ...
<xs:choice ...
<xs:any ...
<xs:all ...

Of course this pretty much means to be safe, you need to stick with a <xs:sequence> of <xs:elements>. However, I was a little surprised to see that a <xs:simpleType> <xs:restriction> on a xs:string generated a very nice enum. Oh, News Flash! Kirill just responded to my email (hey, what's he doing on email this late?) and pointed me to some [internal] beta documentation that very clearly defines how all XSD constructs map to DataContracts. The doc looks awesome - I'll be sure to update this entry once it is live on the Web (if I don't, remind me). Okay, but you're not in the clear yet. You see, now we have to navigate the message wrapping issue.

The MessageContract

Because the DataContract is all about simplifying interop and the object model (OM), it hides wrapping element from the code, but (obviously) not from the WSDL. So, if you're going to import your handcrafted WSDLs, you need to know how to represent the wrapper "message" in WSDL in such a way that you don't have to deal with them in your OM. I think the easiest way to explain this part would be to start with a fragment of a WSDL and show what must change to get the right stuff in code. Consider this:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:srvc="http://MyOrg.HrSrvc.SrvcContracts/2006/10"
                  xmlns:data="http://MyOrg.HrSrvc.DataContracts/2006/10"
                  targetNamespace="http://MyOrg.HrSrvc.SrvcContracts/2006/10">
<wsdl:types>
    <xs:schema elementFormDefault="qualified"
                   targetNamespace="http://MyOrg.HrSrvc.DataContracts/2006/10"
                   xmlns:tns="http://MyOrg.HrSrvc.DataContracts/2006/10">
      <xs:element name="Employee" type="tns:Employee"/>
      <xs:complexType name="Employee">
        <xs:sequence>
          <xs:element name="ID" type="xs:int"/>
          <xs:element name="Name" type="xs:string"/>
        </xs:sequence>
      </xs:complexType>
    </xs:schema>
</wsdl:types>

<wsdl:message name="AddEmployeeSoapIn">
    <wsdl:part name="request" element="data:Employee" />
</wsdl:message>
<wsdl:message name="AddEmployeeSoapOut">
    <wsdl:part name="response" element="data:Employee" />
</wsdl:message>

<wsdl:portType name="IEmployeeManager">
    <wsdl:operation name="AddEmployee">
      <wsdl:input message="srvc:AddEmployeeSoapIn" />
      <wsdl:output message="srvc:AddEmployeeSoapOut" />
    </wsdl:operation>
</wsdl:portType>

<wsdl:binding name="YouGetTheIdea"/>
</wsdl:definitions>

Yes, I know I'm sending and receiving the same type. I'm trying to balance between brevity and reality (cut me some slack). Hopefully at this point I have some contract-first readers nodding their head thinking, "Ok, I'll buy that - seems reasonable enough." Now let's look at how we would have to write this to get the nice dev experience with WCF ('cause this won't create it).

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:srvc="http://MyOrg.HrSrvc.SrvcContracts/2006/10"
xmlns:data="http://MyOrg.HrSrvc.DataContracts/2006/10"
targetNamespace="http://MyOrg.HrSrvc.SrvcContracts/2006/10">
<wsdl:types>
<xs:schema elementFormDefault="qualified"
   targetNamespace="http://MyOrg.HrSrvc.DataContracts/2006/10"
   xmlns:tns="http://MyOrg.HrSrvc.DataContracts/2006/10">
<xs:element name="Employee" type="tns:Employee"/>
<xs:complexType name="Employee">
<xs:sequence>
<xs:element name="ID" type="xs:int" nillable="true"/>
<xs:element name="Name" type="xs:string" nillable="true"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
<xs:schema elementFormDefault="qualified"
   targetNamespace="http://MyOrg.HrSrvc.SrvcContracts/2006/10"
   xmlns:data="http://MyOrg.HrSrvc.DataContracts/2006/10"
   xmlns:tns="http://MyOrg.HrSrvc.SrvcContracts/2006/10">
<xs:import namespace="http://MyOrg.HrSrvc.DataContracts/2006/10"/>
<xs:element name="AddEmployee"/>
<xs:complexType>
<xs:sequence>
<xs:element name="request" type="data:Employee"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="AddEmployeeResponse"/>
<xs:complexType>
<xs:sequence>
<xs:element name="AddEmployeeResult" type="data:Employee"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>

<wsdl:message name="AddEmployeeSoapIn">
<wsdl:part name="parameters" element="srvc:AddEmployee" />
</wsdl:message>
<wsdl:message name="AddEmployeeSoapOut">
<wsdl:part name="parameters" element="srvc:AddEmployeeResponse" />
</wsdl:message>

<wsdl:portType name="IEmployeeManager">
<wsdl:operation name="AddEmployee">
<wsdl:input message="srvc:AddEmployeeSoapIn" />
<wsdl:output message="srvc:AddEmployeeSoapOut" />
</wsdl:operation>
</wsdl:portType>

<wsdl:binding name="YouGetTheIdea"/>
</wsdl:definitions>

The highlighted areas are the parts I added/changed from the first snippet. It’s after midnight now. I’ve learned the beta of Windows Live Writer I was using has a length limitation and doesn’t color XML snippets (yes, I did this manually for your reading pleasure). So rather than continue to wow you with my use of compelling prose, I’ll just bulletize (see?) the significant parts:

· What’s up with the nillable=”true” on the data types? That actually turns out to be pretty critical. I haven’t really thought to much about why yet, but without this construct, it complicates the OM bigtime.

· What about that new schema … doesn’t that complicate the OM? Surprisingly not! It won’t even show up in the generated code. Notice how it imports the existing schema to reference the existing types, which do show up in the code. If you don’t explicitly create this wrapper, it will think the first element it finds (Employee otherwise) is the wrapper … yuck.

· Can the wrapper elements (AddEmployee & AddEmployeeResponse) be in the same namespace as the data type (Employee)? Well, that depends. They can if that namespace just happens to be the same as the service. In other words, the wrapper schema has to share the same namespace as the service. It doesn’t matter if the data types are in the same namespace or not.

· Don, is the fact you named the wrapper elements “AddEmployee” and “AddEmployeeResponse” important? Yes. If you don’t follow this convention, you’ll see these as types in the code … yuck!

· Let me guess, it’s also important that I name the data:Employee elements “request” and “AddEmployeeResult” respectively? Well, not really so much. If you name them something else, like “RequestMessage” and “ResponseMessage,” the System.ServiceModel.MessageParameterAttribute will step in to make sure the response message is correct on the wire, but it won’t affect the OM so much. It will look like this:

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]

[ServiceContract(Namespace="http://MyOrg.HrSrvc.SrvcContracts/2006/10"]

public interface IEmployeeManager

{

[OperationContract(Action="...", ReplyAction="*")]

[return: MessageParameter(Name="ResponseMessage")]

Employee AddEmployee(Employee RequestMessage);

}

· Alright, what’s up with the “parameter” message part names? Yeah, that’s important too. That basically says this contract is wrapped and not bare.

I think that’s about it. I’ll update this entry if I think (or learn) of anything else, but I’m going home now. Hope you find this helpful. BTW, I was listening to the Lemonheads the entire time I was putting this together … pretty cool.

WCF Guidance Packages now available for consumption

donsmith — Thu, 31 Aug 2006 19:21:56 GMT

If you've been following the Service Factory project, you'll know that we had to put the WCF guidance on hold for a little while as we were getting the ASMX Service Factory released. Well ever since it was released, we've been working on getting caught up on the WCF guidance. This actually took longer than expected because in addition to making the WCF Feb CTP -> July CTP changes we felt the need to fix a bunch of the bugs we identified in the similar ASMX GPs so now there is some fidelity between the two.

Is this release of the Service Factory going to go down like the last one? You know, that is a great question. If you mean, "Are you going to release regularly to the community?" and "Are you going to solicit as much feedback from us as possible?" the answer is absolutely yes! As a matter of fact, we're even trying to improve.

Drops will be more regular and predictable - monthly to be exact and at the end of the month to be specific
We're separating the documentation drops from the code drops. They will also be released monthly [in CHM format] ... they will just be 2 weeks after the code drops
I've changed the way we're making the known issues available. Rather than putting some of them in the readme file, now you can find all of them in an Excel spreadsheet. Just Ctrl-F the issue you're looking for.

As always, I'm interested to know what you think about these changes. What would make is easier to follow this project?

Side note: I think it's still a little strange for some people to realize the impact they can have on a team, like patterns & practices, where "customer connected engineering" is the basis for everything they do, how they do it, and what they deliver. There aren't too many teams [even in Microsoft] that are applying this amount of feedback from their customers.

Anyway, check it out and let us know what you think. We're listening.

Partial Classes & the Service Factory

donsmith — Wed, 09 Aug 2006 19:27:00 GMT

I just posted the Service Factory Hands-on Labs to the community workspace and I learned something while I was putting them together. So, I'm going to do 2 things in this post. First, I'm going to do a little cheerleading for partial classes, then I'll talk about an issue Service Factory currently has since it is related to partial classses.

As you may already know, one of the most compelling uses of partial classes is when code is being generated. The code generator will create a class with the partial keyword and any modifications will take place in a different file so the generated file can be regenerated at any time without loosing changes. What I didn't know was that you can also establish an inheritance relationship in that hand-written partial class and you can leave the other one completely untouched. For example,

MyClass.generated.cs

public partial class MyClass : IMyInterface
{
    private int foo;
    public int Foo
    {
        get { return foo; }
        set { foo = value; }
    }
}

MyClass.custom.cs

public partial class MyClass : MyBase, IYourInterface
{
    private string bar;
    public string Bar
    {
        get { return bar; }
        set { bar = value; }
    }
}

I wouldn't be surprised to find that this capability explained in the C# docs, but it was way cool to find out about it on my own. It's totally fitting when it comes to the wave of modelling, guidance automation, and related efforts and technologies coming out now. If you knew all that already and found my epiphany boring ... sorry, I just had to convey my delight.

Now I get to convey my sadness. As it turns out, we (or anyone else) didn't find this until after we ship. Don't get me wrong, it's not the end of the world ... it's not like it's going to cause your spouse to leave you ... it just forces you to write more code by hand ... until we fix it :) Basically, when you go to create the repository classes, the recipe doesn't reflect on the business entities - it's just looking at the files ... so it thinks there are 2 different classes instead of just one, which also tends to hide the members on the base class. This is what you see:

A little extra coding won't hurt anyone ... heck, if you check out the hands-on labs, I even show you what the extra mapping for in and out parameters looks like. We'll also be posting a fix to this issue to the community eventually.

Service Factory now available for download!

donsmith — Sun, 30 Jul 2006 22:54:00 GMT

Before I get ahead of myself, which comes pretty easy for me J, here’s the link to learn more about and download the Service Factory.

Wow, I’ve been waiting 8 months to write this blog entry. After months of planning, arguing, development, sleep deprivation, testing, writing, and making sure all of that wasn’t in vain, the Service Factory has actually made it onto MSDN. Since this is MY blog, I feel like I can be more personal than the other announcements I’ve written recently. This release actually means quite a lot to me. Not only is it the first p&p deliverable I’ve been involved in from the VERY beginning, but I truly believe it will revolutionize the way organizations build services. I believe it can have this impact because the deliverable has seen a huge amount of customer and community involvement and it has a very solid future. We’ve been building the next version, which will include WCF guidance, since we started this [ASMX] release. AND we already have a good idea what the v3 will look like.

If you’re building services today and don’t know what I’m talking about, I would STRONGLY encourage you to spend some time evaluating Service Factory. Not only will it give you confidence that you are building services the right way today, but you’ll have all of the guidance you need to ensure you’re on the right track to build or migrate to WCF services in the future. I’m tellin’ ya, this is bigtime!

I’m working on some hands-on labs right now that I hope to have done within a week. This will really help you get up to speed quickly. I’ll post another entry once I’ve posted them on the community workspace. For now the webcast and the arcast should be good enough to get you started. Let me know if you have any questions.

Just Published: Service Factory ARCast

donsmith — Sun, 30 Jul 2006 21:38:00 GMT

Ron Jacobs did a load of ARCasts at Tech-Ed in Boston this year. One of them was with Shy Cohen and I about the Service Factory. Well, I just got an email from Ron that he's gotten around to publishing it on Skyscrapr. I can't imagine how many of these things he has queued up that he still has to publish. Anyway, go check it out and let us know what you think. I'd like to do more of these with Ron, but I want to make sure I'm talking about the stuff you're interested in. Whadda ya think?

How Teams Build Services

donsmith — Mon, 17 Jul 2006 21:35:00 GMT

With all this talk of software factories, it's important that we understand the different ways teams will use them to build services. I talk to a lot of customers and, of course, there are several different approaches a team might choose. I hope this post will be informative, but hopefully, the comments will also identify new approaches and/or confirm the ones below.

When building a solution that involves distributed services, there are a number of things the team must build: the service interface (operations and their messages), the business logic (domain model entities and processing logic), the data access layer, the proxy/service agent that consumes the service, and the client that uses the proxy/service agent. There are also several roles in the team that perform various tasks: the solution architect, the domain expert, and the developers. I understand there is often a fine line between a solution architect and a lead developer - give me some slack here :)

In every case I've seen, the team building the client application is also the team that is building the proxy/service agent. However, that's often not the case when it comes to the service interface and the business logic. There are various approaches the architect and developers might make when building the service side (they may or may not be building the consumer(s) of the service). More often than not, the architect will define what the service interface looks like and the dev team will implement the interface. The Service Factory enables at least 2 major scenarios:

Solution architect provides a baseline. This baseline is an executable, foundational starting point for the service that the dev team will build upon. Among other things, this baseline will include the service's operations and their messages, message exchange patterns, and possibly selected areas of risk that cross-cut all operations (i.e. instrumentation, security, exception management, etc). It's likely the factory will be used to build this baseline and the dev team will continue to use this (or a different) factory to build out the rest of the implementation based on the requirements set forth by the domain expert. This approach is common when there is a smaller team responsible for the services and a different team is responsible for the business logic.

Solution architect provides a factory. The factory being used (i.e. Service Factory) is modified by the solution architect to include the practices and patterns that have been identified by the organization (naming conventions, framework components, cross-cutting concerns, etc) and it is deployed to the dev team. The dev team will then use the factory to build the service's interfaces and the implementation (and all layers of the application). This approach is common when the same team is building the service and its implementation.

I suspect there are variations of these and I think they would be interesting. Think about how your team builds services today. Are you happy with how the team is structured (does it work)? Are you using some form of code/config generation? Are you building baselines or a factory today and have a sense of the best way it should be used in your team(s).

Since this post was geared toward teams, I didn't talk about the single individual who is building the whole solution. I know this is also a very common scenario and, of course, factories can still be a great productivity booster and a means to provide a lot of consistency in the services being built.

If you're building Web services and you're not familiar with Service Factory, whew ... you have some catching up to do ... and just in time. Patterns & practices should be releasing to MSDN by the end of the month. Let me know if you have questions or comments?

Service Factory: Editing (part 1)

donsmith — Mon, 15 May 2006 10:45:00 GMT

For this installment, I'm illustrating 2 examples of what I call "level 1 changes" to a guidance package. These are the easiest kinds of changes that don't even require any code changes. I'm also using the (very improved) May community drop and you'll get to see a very small peak at the security guidance package. Cool stuff :)

File: ServiceFactory-Editing1.wmv
Length: 18:32
Size: 5.89 MB

Service Factory: Entity Translation

donsmith — Fri, 28 Apr 2006 23:41:00 GMT

For the third installment I've decided to talk about the entity translation (mapping) capability of the guidance package. Specifically, this is mapping between the entities that are [de]serialized to/from the wire representation and the entities that represent the business domain model. This time I used a high-quality mic (Shure) and better software (Camtasia Studio), but WMV is still the best output format for this delivery mechanism (MP4 isn't an option). I also tried 1024 x 768 instead of 800 x 600.

File: ServiceFactory-Mapping.wmv
Length: 15:15
Size: 5.93 MB

Service Factory: Contracts

donsmith — Thu, 20 Apr 2006 11:54:00 GMT

Here's the second installment of my blogcast series on Service Factory. In this one I show how to create WCF data contracts and service contracts. It's a little bigger and longer than I would have preferred, but since I was building the project (a wine rating app) from scratch, I guess that's what took longer.

File: ServiceFactory-Contracts.wmv
Length: 25:48
Size: 8:51 MB