AJ's blog

November 23, 2014

WCF Policy – Part 1: What is policy about?

Filed under: .NET, .NET Framework, SOA, Software Architecture, Software Development, WCF — ajdotnet @ 3:16 pm

Remember what I described during the introduction? Switch a feature on on the server, and the WCF takes care that this information gets pushed through to the client, at runtime client and server work together to fulfill the demand, and on top of it the developer can interfere if necessary.

Add the tiny fact that the “feature” in question usually adheres to some standard, and you have a policy and its implementation – in our case a “WCF Policy”. Let’s look into this a little more in detail, as this defines our to-do-list for the upcoming posts.

Note: This post is part of a series. The TOC can be found here

Policy explained…

The world of services is based on various standards. These standards provide the set of features to choose from. Defining how a standard is employed by a particular service is actually defining the policy for said service.

Now, bringing this – so far abstract – concept of a policy to live in WCF includes several aspects:

  • Initially the developer needs some way to activate the feature on the service (or – rarely – the client), i.e. to switch it on and configure the details.
  • At design time the policy has to be advertised by the service. The most basic aspects like transport protocol and message format are already addressed in the WSDL and XSD. For everything that goes beyond that we have WS-Policy. On the server the information needs to be put into the WSDL, on the client it needs to be evaluated to generate a respective client proxy.
  • At runtime the policy has to be implemented by some runtime component; again, client and server.
  • Additionally, information implied by the policy should be accessible by the developer. Depending on the actual demand, this may be informal, he may be able to interfere, ore he may actually be required to provide additional input. (Say the username and password for basic authentication.)


OK, let’s make this a little more tangible and have a look at how it applies to employing WS-Addressing in WCF. This will also define the to-do-list for our own custom policy…

Initially the developer needs to declare that his service uses WS-Addressing. WCF covers WS-Addressing through different bindings. WsHttpBinding does it implicitly, a custom binding configures SOAP and WS-Addressing versions as part of the message encoding:

The binding also takes care of advertising the policy in the WSDL. Since WSDL itself has no knowledge of WS-Addressing, WS-Policy comes into play. WS-Policy is by itself a rather dull standard. It merely defines how to place additional information (particularly for the use of policies) in the WSDL. In our case it might look like this:

The element wsaw:UsingAddressing is called a custom policy assertion provided by WS-Addressing – Metadata – in general an arbitrary XML fragment. WS-Policy also provides means to define combinations and alternatives between policy assertions.

WCF also addresses the client side by generating a client proxy from a respective WSDL. This process includes handling policy assertions and generating the respective configuration (e.g. by choosing the appropriate binding) or code.

At runtime the actual behavior kicks in: The WCF client automatically generates a message ID for the SOAP request and includes it in the message as SOAP header:

The server takes the message ID and includes it in the reply message using the RelatesTo SOAP header.

Additionally the developer can access the message ID on the server and manipulate it, as he likes.


To summarize this, here’s what makes up a policy in WCF:

During design:

  • Definition of the underlying standard

During development:

  • A way to switch the policy on and to configure as necessary
  • Advertising the policy in the WSDL
  • Evaluating the policy assertion during client proxy generation

During runtime:

  • Establishing the default behavior on server and client
  • Providing an interface to the developer

And this defines what we’re going to have to do – in the following posts…


That’s all for now folks,


Building Your Own Policy with WCF

Filed under: .NET, .NET Framework, C#, SOA, Software Architecture, Software Development, WCF — ajdotnet @ 2:55 pm

Flexibility and extensibility of WCF is really great. You need a feature provided by the platform? Just switch it on, via code or configuration, and all the bits and pieces follow suit. The fact is advertised in the WSDL; the client proxy generation will pick that up and produce respective code and configuration; both, client and server, do their part to make it work at runtime; and last not least the developer usually gets the means to access or manipulate the respective information, should the need arise.

Wouldn’t it be nice to have the same apply to your custom demands, demands not covered by the platform? Demands like…

  • New versions of standards you need to support, but which are not supported by the platform yet.
  • Homegrown authentication schemes.
  • Tenants for multi-tenant solutions.
  • Billing information for services in B2C scenarios.
  • SLA and diagnostics information for operations

Whatever the reason, it would be very nice if we could implement our custom policy in a way that the application developer could use it in a way very similar to policies provided by the platform.

The good news is: It is actually possible to support custom demands in a way very similar to the built-in features of WCF.
The not-so-good news: It is not that simple or straight-forward to do, as there a a lot of bits and pieces working together – and no single information source putting them together. Well, this is what I’m trying to accomplish…

So, here’s the agenda for this little adventure:

Design time aspects:

Runtime aspects:

Looking back:

Quite a bit more than one post…

So stay tuned…

That’s all for now folks,

October 19, 2007

Talking to the Windows Service

Filed under: .NET, .NET Framework, SOA, Software Architecture, Software Development, WCF — ajdotnet @ 9:15 pm

Note: This is part of a series:
1. Talking WF (introduction)
2. Workflow Instance State Management
3. Workflow Communication and Workflow Communication Clarification
4. Hosting WF
more to come (error management).

The last post left us with the web application residing in IIS and WF hosted in a Windows Service. Separated like a divorced couple. Now we need to setup some communication between them. The means of choice? WCF of course. (There is a choice?)

I’m not going into too much details about WCF here as this series is devoted to WF and the documentation for WCF is considerably broader than the WF related information. For hosting of WCF in a Windows Service have a look at How to: Host a WCF Service in a Managed Windows Service. For a more elaborate example including WF Integrating Windows Workflow Foundation and Windows Communication Foundation will show you how to host the WF engine as service extension (gee, the service pattern again).

‘S’ervice or ‘s’ervice?

Let’s have a look at the architecture: What will become of our Windows Service if I attach a WCF interface to it? Will it become a Service in the SOA sense (capital ‘S’!)? Do we therefore need to set up HTTP bindings, WS-Security (my vacation is certainly important enough to be protected!)? Are we going to advertise the Service so that a customer can plug into it? Probably not. None of it. From a logical point of view the WF part is still part of the business logic of our application as the reason to separate it was purely technical. It will therefore become an internal service (see WebService? What do you mean, „WebService“?), lowercase ‘s’!.

WCF actually supports internal services quite well with the named pipe binding. It’s is a binary, efficient binding and it is restricted to one machine (the binding, not named pipes in general of course). This might rule out distributing the two parts on different machines, but seriously, we don‘t have that many employees (yet).
Windows actually also „supports“ that choice by making it very hard to choose HTTP instead. (The “very” stems from the fact that it’s hard to diagnose the reason for the problem. There is solution, though not a pretty one, all in the name of security.)

The fact that we factored the WF engine out of our web application was not intended to change the logical architecture more than necessary, i.e. the workflow is still part of our business logic:


However the physical architecture is somewhat different:


The danger here lies in misinterpreting the physical architecture as logical architecture. (It’s actually debateable whether the call to the Windows Service originates from the DAL or the BL. Don’t sweat it, it’s of no consequence.)


The demand of our application is fulfilled, but let‘s think a bit more about the Service notion. What if I actually wanted a Service in the SOA sense, one that is publicly available?

In this case I would still propose the very same approach for the Windows Service and an accompanying web application. The web application would consist of a publicly available Service (WCF hosted in IIS, e.g. a Web Service), part of the presentation layer, that handled the communication with the caller (validation, security, versioning, ….). It would implement the service interface that was developed during the contracting phase. Internally it would talk, again using WCF, to the Windows Service, just like above. For a prototype SOA ecosystem based on this idea (and being a little more fleshed out) have a look at Security analysis on WCF for the German Gouvernment.

For a series about WF this post was kind of a diversion. Yet I think it is part of the architecture implied by the employment of WF, therefore I kept it in. The next post will look into robust processing, as promised in a previous post.

Quick! How many different notions of the word ‘Service’ did you count in this post? 😉

That’s all for now folks,

kick it on DotNetKicks.com

February 23, 2007

Security analysis on WCF for the German Gouvernment

Filed under: .NET, .NET Framework, SOA, Software Architecture, Software Development — ajdotnet @ 10:54 pm

Something I was waiting for but nearly missed: Michael Willers has announced the security analysis on Windows Communication Foundation he and his collegues did for the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI).

I had the luck to hear Michael talk about this stuff last october. There where two interesting points in his talk:

  1. He took us through some threat modelling. That may be intersting from a security point of view but what impressed me more was that this was the most sound and structured architecture review I ever saw.
  2. Michael emphasised the fact that developing a secure application was only the first part of the deal. Deploying it — or more to the point secure deployment — turned out to be a challenge of its own. Consequently the statement on his blog:

“The results of this study demonstrates how to implement and securely deploy service oriented distributed systems on the Microsoft .NET Platform. “

Documentation and code (under GPL) can be obtained at the BSI site:

“Beside the complete source code of the WCF reference application the BSI distributes manuals covering WCF specific architecture aspects, authentication, data access, development autonomy, distributed error handling, the hosting environment, transport security, securing resources, and secure service set-up and installation.”

It’s definitely worth a closer look.

UPDATE: Microsoft has provided some of the results as templates and libaries for download. See here (Michael’s announcement) and on the MSDN CAS Tools & Best Practices site (both in German, sorry, but the downloadable content should be in english).

PS: The BSI is “the central IT security service provider for the German Government.” (http://www.bsi.bund.de/english/index.htm)

PPS: The usage of voting machines for elections in Germany does not seem to require IT security 👿 , therefore they are checked and certified by the “Physikalisch-Technische Bundesanstalt, PTB“.

“The Physikalisch-Technische Bundesanstalt (PTB) is the national metrology institute providing scientific and technical services. PTB measures with the highest accuracy and reliability – metrology as the core competence.” (http://www.ptb.de/en/zieleaufgaben/dieptb.html).

PPPS: And by the way: Germany uses Nedap machines, the ones you can play chess with…  😈

That’s all for now folks,

kick it on DotNetKicks.com

February 10, 2007

Java EE, R.I.P.?

Filed under: Java, SOA, Software Architecture, Software Development — ajdotnet @ 12:21 am

After the last post I still owe you an opinion about “Analysts see Java EE dying in an SOA world“. Well, here it is (perhaps a little overstated):

This article is fundamentally flawed. It confuses the SOA architectural approach, SOA environments and frameworks, services and service implementations. It implies wrong architectural attempts to prove the inability to deliver something upon it. It ignores todays tool ladden development environments that manage complexity quite well. It even dismisses Java as a plattform — for reasons that would also apply to .NET –, at the same time contradicting itself.

I picked just some points to justify may statements:

  • “The Java EE world is fundamentally not built for SOA”. SOA is about architectures that (technically speaking) deal with message exchange patterns between independend services. Java EE on the other hand is an implementation technology for those services, i.e. it covers the inner workings of a service and its interface. For this Java EE is perfectly suited. Confusion of SOA and service implementation.
  • Also the same paragraph states that “Java is specifically a framework for implementing n-tier architectures” which has been the architecture of choice for scaleable and reliable web applications even before they have been adorned with SOAP interfaces. Contradiction.
  • “Object orientation (OO) as implemented in Java EE does not fit well with the service orientation that is the heart of SOA”. This implies that the OO approach is used at the SOA level, i.e. accross services. This is exactly what remote object technologies (CORBA, DCOM, RMI) tried to do. They failed — hardly any news at all — and services entered the stage to address the respective problems. Implication of wrong architectural attempts. (Again, this does by no means rule out Java as implementation technology for services itself.)
  • “It’s the method in which you’re exchanging the data that matters, not the programming model behind the data.” So, if the programming model does not matter from a SOA perspective, why dismiss any programming model at all? Why argue about virtual machines or portability in the first place? Contradiction.
  • “You’ll see that Java EE focuses on providing a framework for scalable n-tier architectures like those that large, transactional Web sites require”. Which is also exactly what business services need. Contradiction or just lack of understanding? 
  • “However, if you were to set out to create an enterprise-class framework for SOA…” Now what is that? A framework to unify the service implementations? And I thought “the service orientation makes the need for a unified platform such as Java EE irrelevant.” Contradiction. Or does this refer to some kind fo SOA plattform, say an ESB? Who just said “it’s not what’s serving up the communications that’s important, it’s the communications itself.” Contradiction. And by the way: The only noteable SOA plattform not built on Java is MS BizTalk.

Now, I can understand that analysts riding the SOA hype need to attract attention and statements that strong do that especially well. But these staements do not do them credit, rather they show some vital lack of understanding of SOA* — or deliberate obfuscation. Which one, I cannot say. I can only hope that they have been quoted distortingly or out of context.

* It cannot be lack of understanding of Java EE since one of the quoted analysts is an author of well regarded books on Java (J2EE Web Services and Enterprise JavaBeans 3.0 — which I own myself. Sic!)

As I said: This may be overstated, but it’s straight to the point. And it’s only an opinion, no insult intended!

So, well… . I — yeah, that is me, the one who usually signs its posts with AJ.NET — can firmly stand up and announce publicly and unequivocal with loud and clear voice:
Java EE ist still alive and kicking! Any reports allegedly anouncing his death are wrong.
As we say in german: “Totgesagte leben länger…” (proverb, something like “people declared death/written off live longer…”).

Please note that I’m not saying that the role of Java EE (read EJB) is not changing: Au contraire! It is quite obvious that lightweight approaches gain more and more momentum in situations where EJB is overkill. But there still are complex demands that ask for transactional and component life time services, security, operations support, etc.. I guess it boils down to “use the right tool”. However, the fact that our toolbox has more items in it does not mean one should throw away the “older” tools. Usually they got old because they had value.

That’s all for now folks,

February 2, 2007

Will somebody please defend Java EE?

Filed under: Java, SOA, Software Architecture, Software Development — ajdotnet @ 8:50 pm

Some time ago a fellow programmer pointed me to “Analysts see Java EE dying in an SOA world” and asked about my opinion. Since then it always lingered in my mind to shape my thoughts into a blog post… — but that will have to wait!

Since I did not want to do the nth repetition of things already said before, I began with searching the web. Given the nature of the article and the fact that it is 6 months old, it is not surprising that I found more than a few pages. Google lists ~400 hits. What I found to be quite interesting is what the various replies said — and what they didn’t say.

The immediate replies fall in three different categories:

  1. The “me too” replies: They simply link to the article or quote and rephrase in the attempt to explain what was clear in the first place. They don’t offer an own opinion. This is the biggest group in the set of replies.
  2. The “that is not true!” and “how dare you!” replies: They simply state that the article is wrong and that they would have never thought such insolence possible (they tend to be personally offended). What they don’t do is to back up their opinion. Those replies are numerous as well.
  3. The by far smallest group is the group of more or less usefull replies, replies that offer an opinion. The opinions vary in their support and rejection of the article and I certainly don’t agree with all those opinions. But that doesn’t matter, I can live with that. Different opinions are a good thing in itself. One of the better replies is probably “Is JAVA EE Dying with SOA Adoption?“.
    However! All those replies picked just one or other aspect of the article. I could not find one that addressed the article as a whole, none that mentioned the fundamental problems*.
  4. In the interest of fairness I have to admit that there is a fourth group — luckily not all too numerous –, the “I always knew it!” replies from the .NET camp (e.g. this one).  

Far more can be gained by not looking at immediate replies but at the discussions triggered by them. I found particularly those forums and comments to be … well, “interesting”:
And of course the obvious suspects:

This is a very sorry result. A controversial article that is sure to draw attention actually got very little direct response in terms of hard facts. No reply I found was able to dismount the article. To get better arguments I had to look at various discussions. Those discussions however contained all kinds of opinion: wrong and right, objective and religious, informed and misled — and of course the usual share of off-topic and “unpleasant” replies.

Controversial articles are a good thing. They may show new perspectives, revive deadlock situations, or just generally shake up things a bit. If the dust settles down, people should have at least a better understanding of the topic. However (in this particular case) the debate was held in relatively closed communities, not in the open limelight in which the article was placed. People just reading newstickers or otherwise not part of the respective developer communities (usually the ones with the money to spend on projects) won’t even know it took place. That’s a little unsatisfying.

PS: Please note that I checked only a part of the search results. If I missed the one article that really gets to the point, please provide that link. Thank you.

* just stay tuned, I’m not finished yet 😛 .

That’s all for now folks,

October 22, 2006

WebService? What do you mean, "WebService"?

Filed under: .NET, .NET Framework, SOA, Software Architecture, Software Development — ajdotnet @ 3:27 pm

When people (make that “developers”) start talking about WebServices I immediatelly get cautious. Once they use phrases like “other clients”, “probably different plattform”, and “serialization” in the same sentence I get that weary feeling, like I just eat something bad. Ironically if I ask what they actually mean when they talk about “WebService” I am the one being looked at as if I have been out of business for the past 5 years.

Well, I cannot blame them. Actually I blame Microsoft. And IBM. Bea. They made it far to easy to create something they called WebService directly from code (i.e. SOAP wrappers on objects). Then they invented SOA and talked about something entirely different which they also named WebService. It is not as if they don’t try, actually they try very hard to tell people the difference. In fact there are bright people within those companies who do nothing else. Yet this sometimes strucks me as damage control; damage caused by carelessly giving two very different things the same name – or rather by sticking with the name when WebServices evolved into something completely different.

Just as a side note: Did you notice I didn’t mention SUN? They are not to blame. They jumped on the train when it was already on its way and even then they did it reluctantly.

Here are the differences I am refering to:
There is a technology stack (namely HTTP, SOAP, and WSDL, possibly augmented with WS-* standards) commonly named “Web Service” on one hand. And on the other hand we have the architectural concept of services – nowadays allways in the context of a SOA -, which is usually also named “WebService” because WebServices are the predominant/canonical implementation technology for this concept. And because WebServices are the predominant implementation technology people often confuse the concept and the technology. Thus, when they use the technology they asume that the bennefits of the service come for free. (That is “service” in the SOA sense – unfortunately “service” is also a term that has very diverse meanings).

In order to clearly distinguish both kinds I usually use the terms “internal/private WebService” (the technology focused ones) and “external/public WebService” (following the service concept). The (somewhat idealized) definition of these two kinds of WebService goes like this:

Internal/private WebServices are used within a logical application as a means for distribution.
Both sides (client and server) are under control of the development team, both are deployed in unison, both have the same notion about the data model. Actually the fact that a WebService (or rather HTTP/SOAP) is used is just an implementation detail. One could also think of any other kind of remote method call technology (Remoting, DCOM, RMI, FTP, …) without affecting the application architecture.
These WebServices are meant to be never called from outside the application.

External/public WebService are published by an application to be used by other independend consumers – consumers you may not even know. These WebServices constitute another UI layer (rather than the interface of a layer). They require contracting, security, versioning, logging, fault tolerance, etc.. In particular this includes developing a separate data model for the interface. This model has to be versionable, stable, aligned with the service calls, and devoid of any implementation details. What you should not do is simply publish the internal data model. Apart from inflicting implementation details on the consumer, the least thing that will happen is that you can’t change anything afterwards without breaking your consumers. In other words: If you did that, you would have built the handcuffs, tied them to your own hands, threw away the key, and jumped in the water. Even good swimmers will drown in this situation. Publishing your internal data structures will get you into trouble. Trust me on this, I can show the scars.

Needless to say that internal WebServices are far easier to implement than external ones. The pitfall created by the similar term is that in my experience most WebServices are implemented as internal WebServices, yet sooner or later someone will use them externaly, expecting the quality and the features of an external WebService. Also quite often certain people (deliberately?) ignore the difference – even if you tell them. Internal WebServices are so much cheaper and a WebService is a WebService, no matter what this bitcounting bonehead (me!) says.

The way I try to avoid this situation consists of one single rule: I observe this clear distinction during design, development, and especially when talking about these things. I use the term WebService for the external kind and put emphasis on the service characteristics. Also I mark them accordingly with price tags – and sorry, nothing on sale today. For internal WebServices I try to avoid that term altogether, rather I use something like “SOAP interface”.

Of course there’s a gray area and sometimes 3 is an even number, yet following this rule will avoid a lot of problems afterwards.

That’s all for now folks,

July 17, 2006

SOA Starting Point

Filed under: SOA, Software Architecture — ajdotnet @ 9:25 pm

As SOA (along with Web Services) is one of my favourite topics, I think it prudent to define a starting point with my first post. (Actually this is not exacly my first “post”, since I used to have some of the following information on my web site, yet I cleaned that part just recently.) I should point out that this post refers to conceptual things rather than implementation or other topics.

Now, the usual starting point would be to come up with a definition. Another one. Adding to the not so tiny number of already existing definitions… . No way!  If you need a definition I recommend Reger Sessions ObjectWatch Newsletter #45: “What is a Service-Oriented Architecture (SOA)?” (October 7, 2003, http://www.objectwatch.com/newsletters/issue_45.htm), which also does away with some misconceptions.

Anyway, the starting point for me lies a little earlier than the term “SOA”. It’s got to do with the “S” in SOA: Pat Hellands work on “Autonomous computing: Fiefdoms and Emissaries” (2002, Microsoft Webcast, http://microsoft.com/usa/Webcasts/ondemand/892.asp — and I could not find it, the link is broken. I know that there are also PPTs from Pat about this topic, yet I couldn’t find any of them publicly available either. If anyone knows some links, please tell me!)
The value of this work lies in doing away with classic (read clients/server like) patterns of data exchange.

Also dating earlier than the term “SOA” is another issue of Rogers newsletters: “The Software Fortress Model: A Next Generation Model for Describing Enterprise Software Architectures” (#36, 17.11.2001, http://www.objectwatch.com/newsletters/issue_36.htm). OK, I know, the link is also broken. But I sent Roger an email asking when/whether it will work again and he has also written a book about that topic [UPDATE]It took but a weekend and #36 was online again :-D. Thanks, Roger! [END UPDATE].
The reason I think this a valuable work is that it defined the landscape of systems/services at the advent of SOA. Many of the issues with implementing a SOA can be understood better with the SFM in mind.

What a starting point. Based on information I cannot deliver :-(… . But it gets better.

Again it was Pat Helland who brought up Metropolis, “A metaphor for the evolution of information technology into the world of service-oriented architectures.” (04/2004, http://www.architecturejournal.net/2004/issue2/aj2metrop.aspx, there was more information on his personal web site, yet since he kind of went out of business, his site is down. What a pity.)
Speaking of evolution, I see Metropolis as the evolution of Rogers SFM in a SOA world where the various services work together and become a living, almost kind of social, interacting eco system.

And back to Roger (it’s like ping pong, isn’t it ;-)): He just published a white paper about “A Better Path to Enterprise Architectures” (04/2004, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/sessfin00.asp, or on his website). He also uses the “analogy of an enterprise architecture to a city plan”, but he takes it further and examins how to evolve the enterprise (rather than the single service) without loosing control.

Well, that’s it so far. These two guys have done tremendous work to describe the large, interdepended, and grossly complex eco systems that we as developers and architects have to deliver, maintain, evolve, and master. To my relief so far, the reality today is (mostly) still some iteratations behind these prospects. However – as Roger pointed out with his examples of failures – this may be the case because we (as an industry) couldn’t yet deliver this vision of eco systems.

That’s all for now folks,

« Newer Posts

Blog at WordPress.com.