It has been a while ago since I found the time to post some blogs. So hopefully a new ‘fresh’ start :-)
Next Tuesday (Jan. 19th 2010) I’ll give a presentation about using BizTalk RFID with the ESB Toolkit 2.0.
My presentation will be about how to start with BizTalk RFID and to use it together with the ESB Toolkit 2.0.
And if you start using the ESB Toolkit 2.0 in which ways can you implement it.
Hope to see you there.
More info can be found at http://www.btug.biz/Home/NL/tabid/81/Default.aspx
I just remembered today that I haven’t uploaded my presentation on Dev Days 2009. So I just did :-)
You can find the presentation at this: link. Unfortunately the presentation text is in Dutch.
If you’ve got any further question let me know.
Since today Microsoft has released the ESB Toolkit 2.0 (formally known as ESB Guidance 2.0) This is good news, as soon as I got my hands into it I’ll let you know :-)
The features (cut-and-pasted from Microsoft ESB Toolkit site)
- Endpoint run-time discovery and virtualization. The service consumer does not need to be aware of the service provider location and endpoint details; a new or modified service provider can be added to the ESB, without interruptions to the service consumer.
- Loosely coupled service composition. The service provider and service consumer do not need to be aware of service interaction style.
- Dynamic message transformation and translation.The mapping definition between distinct message structure and semantics is resolved at run time.
- Dynamic routing. Run-time content-based, itinerary-based, or context-based message routing.
- Centralized exception management. Exception management framework, services, and infrastructure elements that make it possible to create, repair, resubmit, and compensate fault messages that service consumers or BizTalk components submit.
- Quality of service. An asynchronous publish/subscribe engine resolves different levels of service availability and provides high availability, scalability, and message traceability for ESB implementations.
- Protocol transformation. Providing the ability for service provider and service consumer to interact via different protocols including WS-* standards for Web Services. For example, a service provider can send an HTTP Web Service request, which will result in sending a message via Message Queuing.
- Extensibility. Provides multiple extensibility points to extend functionality for endpoint discovery, message routing, and additional BizTalk Server adapters for run time and design time.
According to the ESB Toolkit website the source will also be released in the (I hope near) future.
The following links can be useful:
ESB Tookit download ESB Toolkit documentation download
ESB Toolkit online documentation
ESB Toolkit Forum
ESB Guidance Team blog
ESB @ Codeplex
I enjoyed giving my first presentation at the DevDays. I hope you did as well!
The first part of my sample source code is available. (The demo about using Itineraries in BizTalk ESB Guidance 2.0)
The second part (EDA in action) will come tomorrow.
If you’ve got any questions feel free to drop me a note.
You can get the sample code here: Sourcecode
Thursday the 28th of May. I’ll be presenting at the DevDays 2009 The Netherlands.
I’m going to talk about using BizTalk 2009 & ESB Guidance(Toolkit) 2.0 in a Event Driven Architecture.
The presentation is about Event Driven Architecture and I’ll give an insight to the ESB Guidance(Toolkit) 2.0.
Hope to see you there.
Since last Monday BizTalk 2009 is released for Beta testing. (BizTalk Server Team Blog newspost ) Also ESB Guidance 2.0 has been released CTP. So stay tuned the coming weeks for more information about this new release.
What's new in BizTalk 2009
- Support for .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 - take advantages of the latest developer tools.
- Support for Windows Server 2008 and SQL Server 2008 – full support of Hyper-V, and increased performance and scale.
- EDI - enhanced out of the box support for the most commonly used EDI schema and trading partner management tools.
- Simplify development of mobile applications that expose relevant, real-time business information (RFID Mobile).
- ALM – new support is provided for Team Foundation Server (TFS), allowing development teams to leverage the integrated source control, bug tracking, support for team development, Project Server integration and support for automating builds via MSBuild.
- Enhanced Developer Productivity – improved underlying project system enhances debugging support for artifacts, pipeline components and orchestrations, and enables support for unit testing.
To get the new bits from BizTalk: https://connect.microsoft.com/site/sitehome.aspx?SiteID=218
To get the new bits from ESB 2.0: http://www.codeplex.com/esb
Today I was at the session WCF 4.0 Building WCF Service with WF in .NET 4.0
Many new and very interesting features are being built into WCF & WF 4.0.
Nowadays in WF it's kind of challenging to make a choice between synchronous and a-synchronous:
Synchronous = Simple to author and maintain performs poorly
Asynchronous = Performs well call can be made in parallel, difficult to author and maintain
WF / WCF 4.0 makes that live a bit easier. The configuration and development in WF 4.0 to call asynchronous services is quite a lot easier (Soon with examples!)
The designer for configuring endpoints and WCF activities looks a bit smoother. As far as I can see it 'pre-scans' the *.config file which endpoint to choose, or create your new endpoint.
Correlation is now also with content, so you can relate to values inside the message. You can still use the contexttoken (as in .NET 3.5) but now you have the option to do xpath queries and select based on which kind of content you would like to continue the instance. Only I question myself why xpath? Can't I use objects since it's a datacontract? (Maybe later more info on this.)
Also I saw a live demonstration on Dublin the new hosting platform for WF. Dublin is an extension on IIS. It's some very cool features like:
- Routing connect the right message with the correct version
- monitor al running workflows (with tracking enabled), restart, stop
- Lookback workflows
- See event details on activities in the tracking tool
- More info will come soon.
Conclusion very cool times ahead for WF and WCF.
From the session Architecting Cloud Services at the PDC 2008. Not only which design consideration you might want to take, there's also a lot of more in-depth information about how Windows Azure works is designed.
Yesterday I blogged about the announcement of Windows Azure, and the insight of Azure comes more and more clear. The SDK it out so the information is dropping in step by step.
I think Windows Azure is more then just a Cloud Service. It's remote hosting. All your applications which do something with the Web, can be hosted in the cloud.
The bold and underlines remarks are questions I try to answer later on, because these question I have as well.
I'm sorry that this blogpost seems a bit 'stacato' they are almost a direct note of my sessionnotes.
A nice thing about Windows Azure is that it does 'eat you own dogfood' , for example the storage service makes use of Windows Azure.
So what are characteristics of Cloud computing?
- Scale-out not scale-up
- Add and remove capacity on demand
- Pay for what you use as you go
- Automation is key to reducing cost
Windows Azure goal is to automate life cycle as much as possible
- As a developer you develop your service, then you get your Azure service provisioned, after that Azure helps you to pick up your code.
Like: - Mapping and deploying to actual hardware
- Network configuration
- Maintain goal state:
- Monitoring (Done by Azure)
- React to events
- Service model Guides Automation
- Describes service as distributed entities
- Authored by service developer
- Configured by service deployer
- Logical description of the services
- Same model used for testing and production
- Where is development / test / staging (user acceptance test environment) / production?
WJC: As far as I can see at this moment there's only staging and production.
- Windows Azure Service Model elements
Just a bit like WCF these are the elements which needs to defined in some sort of way. - Service
- That's the set of roles, groups and channels
- Role
- Group
- Endpoint
- Channel
- Interface
- Contract?
Update domain dictate the order of how the updates are being, this gives you the control which what to and when to update. Even rollback en rollforward.
Dynamic Configuration Settings
- There is no registry for services
- Application configuration settings are declared by the developer (declarative) and can be set finally by the deployer
- System configuration Settings
- Pre-declared, same kinds for all roles
- Assigned by the system.
Windows Azure Automation
- Fabric Controller (This is the brain of the system)
- Maps declarative service specs to available resources
- Manages service life cycle starting from bare metal
- Maintains system health and satisfies SLA
- What's special about it?
- Model driven service management
- Windows Azure push button deployment
- This is a an almost automated process, there's some manual intervention needed, for example assign the fault domains and the update domains
- It's can send an message back when an update failed and will rollback.
There's a medium trust code access policy.
Windows Azure is designed highly available.
- Network redunded designed
- Services are deployed across fault domains
- Load balancers route traffic to active nodes only
A thing to think about is how Microsoft is going to manage updates on the cloud servers. In some cases it might happens that an update depreciated some code of you. At this moment only security patches are being applied. But I'm very curiously about the strategy for updating.
The roadmap:
Windows Azure PDC release:
- Automated service deployment from bare metal
- Subset of service model simple set of service templates
- Changing number of running instances
- Simple service upgrades or downgrades
- Automated service failure discovery and recovery
- Hardware management
2009+:
- Expose more of underlying service model
- Richer service lifecycle managing
Design considerations when developing a Cloud hosted Service / Application
Characteristics of Cloud computing
- Scale-out not scale-up
- Add and remove capacity on demand
- Pay for what you use as you go
- Automation is key to reducing costs
Cloud services design considerations
- Failure of any given node is expected
- View each node as a cache
- State has to be replicated
- No one-time install step
- Application need to reinitialize on restarts
- Do not assume previous local state is available
- You have to create some sort of state management, because you can't do any asumptions on in
- Configuration changes due to load or failures
- Handle dynamic configuration changes
- Services are always running
- Service rolling upgrades/downgrades
- Services must handle data schema changes
- Services are built using multiple nodes/roles
- Document your Service Architecture
- Document your communication paths of elements
Other wise nobody doesn't what where, why and how.
- Services can grow very large
- Careful state management at scale is needed
- Some should be available as standard with Azure.
Benefits of adhering to Windows Azure Design Point
What does Azure does for you?
- Windows Azure manages services not just servers
- Tell it what you want and it will automate the details
- Please show me more of that :-)
- System manages services, nodes and network
- Automates service life-cycle management
- Consider where to focus on
If your service becomes big, what is better / more cost effective. Invest in usage or just scale-our. - But this is also very depended of the pricing model Microsoft is going to have.
So this is again really a lot of information, but it sounds promising, blog ya soon :-)
While being at the PDC 2008, a got a first approach on Oslo.
In short Oslo is a large modelling environment which has connections to almost every aspect of .NET development. This seems kind of radical and it probably is. The whole of it still has to be processed in my brains (Which is now running double overtime :-) )
The Oslo platform can be divided in:
- "M"
This is the language where the textual DSL magic happens. - "Quadrant"
The tool for authoring the model visually. - Repository
For the storage of the models which has been created.
So much magic happens at this moment in the M language. It's used to build your textual DSLs.
Textual what?
Yes what I was used to was DSL with squares, round, connectors etc etc. (Singleminded me :-) ) It's kind of cool and also a bit complex. You create your DSL with the M language.
After that you have you environment (Maybe even pseudo language) to give input to your domain model.
More about "M"
See an example of the "M" language:
1: module Microsoft.Samples
2: {
3: type MusicItem
4: {
5: Id: Integer64 = AutoNumber();
6: Album : Text;
7: Artist : Text;
8: Rating : Integer32 where value <= 3;
9: } where identity Id;
10:
11: MusicLibrary :MusicItem*;
12: }
In short: "M" is a language for defining domain models and a textual DSL.
M domain models define schema and query over structured data
- Values, Constraints, and Views
- Natural projection to SQL
So now we know what it is what is it not:
- An object oriented language
- A data access technology
- A replacement for T-SQL
The M Framework
- M is itself implemented as M DSL
- Parser exposed using M DSL machinery
- Type flow exposed as framework component
- SDK ships with an evaluator(MrEPL)
So lot's of new stuff :-)
Also check out my colleague Michel Heijman about his first contact with Oslo.
I'm now in the session on the PDC 2008: WF 4.0 A first look. Just laying on my chair the leaflet: .NET Framework 4.0 Windows Communication Foundation and Windows Workflow Foundation
In that leaflet there was a very nice announcement: Windows Server Dublin.
What's Windows Server Dublin?
"Simplified hosting Experience with Dublin
Windows Server 'Dublin' technologies provide the .NET 4.0 developer with a standard host for WCF and WF application. 'Dublin' will allow you to host your workflow using pre-built developer services in a robust scalable environment - freeing you from writing your own host environment"
Woehooo, that's makes my very happy, it seems that the Workflow Foundation environment gets more and more mature.
This is working together with Visual Studio 10 & .NET Framework 4.0, unfortunately this might take a while before it's really in production. But he it's really worth waiting for.
Found in the announcements (All are very good news and make me even more curious to get my hands on it.)
Q: Will “Dublin” support existing applications built on the .NET Framework? What should customers and partners do today to prepare?
A: Yes. “Dublin” will continue to provide backward compatibility for existing Windows Workflow Foundation and Windows Communication Foundation applications. Customers can confidently begin building applications on top of both Windows Server 2008 and .NET Framework 3.5 today, with assurances that those applications will enjoy the benefits of “Dublin” when it becomes available.
Q: What are the customer benefits of the using Windows Communication Foundation and Windows Workflow Foundation with “Dublin”?
A: The 4.0 release of .NET Framework represents the second generation of the Windows Communication Foundation and Windows Workflow Foundation technologies. For the .NET developer, the 4.0 enhancements include these:
- Simplified coordination of work
- Ability to express applications and services in a way that makes sense to individual teams and businesses
- A framework for durable, long-running applications and services
Q: Will “Dublin” work with the “Oslo” modeling platform technologies?
A: Yes. “Dublin” will be the first Microsoft server product to deliver support for the “Oslo” modeling platform. “Dublin” does not require “Oslo” to operate and provide benefits of hosting .NET applications; however, administrators will be able to deploy applications from the “Oslo” repository directly to the “Dublin” application server. “Dublin” provides model-driven “Oslo” applications with a powerful runtime environment out of the box.
Q: Will “Dublin” work with Microsoft BizTalk Server’s enterprise connectivity services?
A: Yes. The integration server and application server workloads are distinct but complementary; customers want to be able to deploy them separately as needed to support their distinct requirements. For example, customers that don’t need the rich line-of-business (LOB) or business-to-business (B2B) connectivity provided by an integration server will deploy the Windows Server application server to host and manage middle-tier applications. Likewise, customers that need to connect heterogeneous systems across an enterprise, but don’t need to develop and run custom application logic, will deploy BizTalk Server. When customers need both capabilities, “Dublin” and BizTalk Server will work together nicely.
See also: Windows Server Application Server Roadmap
More Posts
Next page »