|
|
|
|
|
|
Geballtes Know-How - für Sie!
thinktecture und DevelopMentor kündigen im Rahmen einer Partnerschaft das erste in Deutschland stattfindende "Enterprise .NET"-Event an. Es wird in der Woche vom 26. Mai 2008 in München stattfinden und im berühmt-berüchtigten "Guerilla"-Format abgehalten: Über 50 Stunden in 5 Tagen! Dominick Baier, Ingo Rammer und ich würden uns freuen, Ihnen alles Neue und Wichtige rund um verteilte Anwendungen auf Basis von .NET bei- und nahe zu bringen.
Lernen Sie, robuste verteilte Lösungen auf Basis der Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), Windows CardSpace und Biztalk Server zu entwerfen und zu implementieren. Der „Guerilla Enterprise .NET“-Kurs zeigt Ihnen, wie man diese Technologien und Produkte anwendet und verteilte Systeme damit erstellt. Dabei wird auf den jeweiligen Stärken der Technologien aufgebaut und versucht, die Schwächen zu umgehen – alles im Sinne Service-orientierter Prinzipien.
Erhalten Sie Antworten auf diese und weitere Fragen
- Was bedeutet Service-Orientierung wirklich?
- Wie erstelle ich interoperable Services?
- Wie kann ich einzelne „Building Block“ Services komponieren?
- Wie funktionieren Sessions und wann sollte ich sie nutzen?
- Wie kann ich lang andauernde Geschäftsvorfälle modellieren und ausführen?
Lernen Sie, skalierbare und flexible Service-basierte Anwendungen mit den aktuellen Technologien aus dem .NET Framework 3.5 zu bauen.
Highlights des Kurses
- Verstehen Sie die Architektur von WCF, WF und Biztalk Server
- Schreiben Sie Services für Internet- und Intranet-Szenarios
- Erstellen Sie robuste lang laufende Workflows
- Verstehen Sie die Unterschiede und jeweiligen Stärken von Biztalk Server und WF
- Erstellen Sie asynchrone nachrichtenbasierte Anwendungen
- Integrieren Sie Services und Workflows mit WCF und WF
Wir würden uns freuen, Sie ab 26. Mai 2008 in München begrüßen zu dürfen - "Take your enterprise .NET programming skills to the next level!"
Registrierung und weitere Informationen können per Email an office@thinktecture.com abgewickelt werden.
[Flyer im PDF-Format]
Infos zum Guerilla-Format:
Anders als bei "üblichen" Trainings werden Sie in den fünf Tagen ständig durch drei (3) Trainer betreut – Montag bis Donnerstag auch bis in den späten Abend hinein. Sie können Ihre Kenntnisse und Fähigkeiten bei Programmier-Challenges mit den anderen Teilnehmern messen und attraktive (und auf jeden Fall auch Geek-)Preise gewinnen.
|
|
|
thinktecture always had really great experts for a variety of technologies and areas of expertise in order to help software architects and developers with problems in their projects - but...
... we were always lacking some guy who knows how to do good user interface design and who knows literally everything about classical Windows programming, Windows Forms design and hacking and last but not least enjoys working with WPF and Silverlight. It was just very hard to find this super-hero - but...
... now he is here:
Jörg Neumann (yeah, he promised to deliver a more reasonable text soon :))
His blog is currently only available in German but I am sure we can force him to switch language.
I am glad, we are all glad - I already had the pleasure to work with Jörg on some POC apps, his knowledge simply rocks.
Oh well: Jörg is also quite a nice guy, although he is from Northern Germany - well...
P.S.: Jörg is also very knowledgable with everything SQL Server, e.g. he has written a book on this very topic (in German).
|
|
|
I had several people asking me for some details about what exactly is fixed in 3.0 SP1 - so here is some more information.
The .NET Framework 3.0 Service Pack 1 fixes the problems that are described in
the following articles in the Microsoft Knowledge Base:
932471 FIX: Error message
when you try to open or to create a protected XPS document by using the XPS
viewer that is included with the .NET Framework 3.0: "Cannot open this document
because your permissions have expired" 932816 FIX: You experience
various problems in Windows Workflow Foundation 935314 FIX: You may
experience issues with Windows Communication Foundation peer channel connections
935315 FIX: The COM+
application cannot start when you use the COM+ Service Model Configuration tool
to expose the COM+ components in the COM+ application 935434 FIX: Error message
in FIPS-compliant systems when you use Windows Communication Foundation to
serialize generic types: "This implementation is not part of the Windows
Platform FIPS validated cryptographic algorithms" 936123 FIX: Error message
when you open a workflow by using the workflow designer in Visual Studio 2005:
"Error loading workflow" 936512 FIX: A memory leak
occurs when you send many messages by using the NetMsmq transport in the .NET
Framework 3.0 938758 FIX: The Unload
method may stop responding (hang) in a Windows Workflow Foundation project
942520 FIX: You may
experience slow performance when you run a Windows Communication Foundation
application
|
|
|
Just to make this point very clear:
ADO.NET Data Services (aka 'Astoria') is not tied to a database, not tied to relational data and surely not tied to the ADO.NET Entity Framework. *Data* in 'Data Service' doesn’t mean 'Database', but it literally just means 'Data' of any kind.
I try to post sample over the coming weeks to prove this point.
|
|
|
Usually, I do not post just "+1"... but this time - and I have been fighting with myself not to rant too much about Volta - I am 100% with Rich.
I just think there is too much "Oh, that is easy: just one attribute and a switch and I'm done"-mantra in there...
Well, keeps me busy :)
|
|
|
Quick note:
Astoria services are PerCall by default. A data service derives from WebDataService<T> which looks like this:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)]
[AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class WebDataService<T> : IRequestHandler, IWebDataService
...
|
|
|
You can access the SSDL (ADO.NET Entity Framework's store schema definition language, and *not* this one here) of your Astoria Data Service by appending $metadata to the base URL, like this:
http://localhost:7777/Services/Data/NW/$metadata
This metadata can e.g. be used to generate client-side code with the WebDataGen.exe tool, like this:
webdatagen /mode:ClientClassGeneration /uri:http://vmxpsp2:7777/Services/Data/NW /outobjectlayer:Northwind.cs
This creates entities which you can use to program against, for example by leveraging the Astoria client API.
|
|
|
The latest Astoria / ADO.NET Data Services CTP also includes a client-side library with support for creating LINQ queries against a REST API - very interesting.
Details can be found here.
|
|
|
The official ADO.NET Data Services (hm, am I the only who thinks that this - again - is not a perfect name...?) documentation doesn't alk about and doesn't show how to self-host your Astoria services - the samples and quickstarts always use ASP.NET/IIS to expose the WCF-based services that Astoria is using.
By looking a bit around in Reflector I managed to create a self-hosted Astoria service which (for this example) is hosted in a Console application.
We have several steps to fulfill our task:
- Create the ADO.NET Entity Model
- Implement your Astoria Service
- Configure endpoint(s)
- Create a ServiceHost instance
Creating the Entity Data Model is no special thing as well as implementing an Astoria service. Just follow the offical steps for the respective topic in the ADO.NET Data Services Quickstart docs.
Astoria uses one generic universal contract for implementing the service base class. The service class you already built above is a derivate of WebDataService<T> and the WCF universal ServiceContract is Microsoft.Data.Web.IRequestHandler which can be found in the Microsoft.Data.Web assembly.
[ServiceContract]
public interface IRequestHandler
{
[OperationContract]
[WebInvoke(UriTemplate="*", Method="*")]
Message ProcessRequestForMessage(Stream messageBody);
}
So everything we need to do now is to create an endpoint definition which uses these artifacts and leverages the webHttpBinding which was introduced in .NET 3.5
<system.serviceModel>
<services>
<service name="SelfHostedAstoria.WebDataService">
<endpoint
address="http://localhost:7777/Services/Data/NW"
binding="webHttpBinding"
behaviorConfiguration="webHttp"
contract="Microsoft.Data.Web.IRequestHandler" />
</service>
</services>
</system.serviceModel>
In order to actually expose our Astoria Service we need to hook up a ServiceHost instance. In our case we will use the WebServiceHost (living in System.ServiceModel.Web) which already takes care about setting up the needed behavior on all webHttpBinding-based endpoints.
WebServiceHost host = new WebServiceHost(typeof(WebDataService));
host.Open();
...
Easy! Now we have a self-hosted Astoria service.
|
|
|
Rich, Jörg and myself had a lot fun building this baby: being able to have an activity to graphically map source and destination objects and properties and not having to resort to a CodeActivity. A little bit like the Biztalk Server mapping editor in a light version.
Rich has all the details.
Download the code for the MapperActivity.
|
|
|
For whom this ever may be useful - I fighted a long time against this... (and got support from the WCF team, BTW)
We have this very vast .NET 3.x end-to-end sample application which covers nearly all of the (senseful :)) features in the .NET Framework. Part of this application scenario is an upload feature where users can upload media files through a common ASP.NET frontend to the web server which then in turn talks to a WCF service that is implemented by a WF state machine workflow. The communication between the ASP.NET app on the server and the WCF Upload Service is via a Named Pipes channel (netNamedPipeBinding).
Recently I ran into a problem which only occured after I moved over to Windows Vista (from XP SP2). And of course, as a lot of us (... yeah, I can hear Dominick yelling at me ...) I was always working as an admin on XP and so my primary account on Vista is also an admin account. Obviously, being an admin on Vista is very different from being an admin on XP if you have UAC (User Account Control) enabled - and you *should* have it enabled, but this is maybe worth another blog entry. When running as an admin on Vista with UAC turned on all processes are by default not running elavated and therefore do not have all the privileges the exact same admin has on an XP SP2 box.
For testing and demonstration purposes I have created a console host application for the WCF-based Upload Service. I start this console EXE and my WCF service starts successfully stating that the NP endpoint has been setup. If I run my test console client against this service everything works as expected. Please note that all processes involved until now are executed non-elevated.
As many others, I started developing and testing the Upload web app in Cassini (aka 'ASP.NET Development Server', WebDev.WebServer.exe). Everything was working like a charm :)
Problems started to occur when I switched over the ASP.NET client application from Cassini (yes - I can hear Dominick yell again) to running in IIS 7. The WCF Upload Service is still the same one, actually the process is still running. When hitting the UploadWeb with the browser and submitting data the ASP.NET app on the server side then tries to talk to the NP endpoint of my WCF service - but: bang!!!
The pipe endpoint 'net.pipe://localhost/tecTeacher/UploadService' could not be found on your local machine.
Hm, what's up here?
The client app (i.e. ASP.NET) doesn't seem to 'see' the Named Pipe... ASP.NET is running in IIS which is running in a Windows Service, namely w3wp.exe. Services in Vista and Windows Server 2008 run in Session0. My ConsoleHost is not running in Session0 but rather in Session1 (you can verify this by using Task Manager and adding the 'Session ID' column to the view). Usually, WCF's Named Pipe support tries to create the pipe in the Global namespace.
If my WCF server process using a Named Pipe-based endpoint doesn't have privileges to create a Global kernel object it silently fails and creates a local one which will not be visible to processes outside of its session. My ConsoleHost app has been started with common privileges, not elevated and therefore cannot create objects in the Global kernel object namespace. This explains the problem that ASP.NET running in IIS sitting inside a Windows Service cannot see the Named Pipe offered by the console EXE.
What can we do to fix this?
a) Run your WCF service inside a Windows Service (which you should do anyway, and not inside a Console)
b) Host your WCF service inside of WAS/IIS (only on Vista and Server 2008) - but be sure to know about the limitations of this approach
c) Run the Console host application elevated (for demo and testing purposes only)
Some more technical explanations can be found in an MSDN article talking about Kernel Objects Namespaces, I am just providing an excerpt which talks about the actual problem:
Starting with Windows Server 2003, Windows XP SP2, and Windows 2000 Server SP4, the creation of a file-mapping object in the global namespace (by using CreateFileMapping) from a session other than session zero is a privileged operation. Because of this, an application running in an arbitrary [...] session must have SeCreateGlobalPrivilege enabled in order to create a file-mapping object in the global namespace successfully. Note that the privilege check is limited to the creation of file-mapping objects, and does not apply to opening existing ones. For example, if a service or the system creates a file-mapping object, any process running in any session can access that file-mapping object provided that the user has the necessary access.
Lessons learned.
|
|
|
Now with VS2008 being released obviously a lot of people also want to run WSCF in it.
I have an updated WSCF.addin file which you need to replace the original one with (the location of the .addin file depends on your install option).
Please note that this has not been broadly tested but customers have reported successful execution of WSCF inside VS2008.
Download WSCF.addin_VS2008.zip
|
|
|
Some heads up wrt to WSCF - this is what I just posted over at the thinktecture forums (which have been quiet from our side for a loooong time, sorry).
Hello everybody,
first of all I really need to apologize the long silence in these forums here - sorry!
To make a (quite) long story short:
We will open source WSCF.blue (the version we are currently building for
WCF) by the beginning of 2008.
WSCF has always been a toy project for us - and as we are very busy in 'real' projects we could not work much on it, sorry again.
The questions still open in this forum will likely not be addressed and answered as we are trying to figure out how to host the source code for WSCF (e.g. on Codeplex).
Please watch my blog at http://blogs.thinktecture.com/cweyer/ to get notified when we are done with WSCF.blue.
Thanks again for using WSCF and providing incredibly useful feedback over the years!
Regards,
Christian Weyer
So, some more to come - but I am now mentally ready to give this baby away...
|
© 2002 - 2006 by thinktecture, Ingo Rammer and Christian Weyer. All rights reserved.
|
|