ESB toolkit 2.0 and BizTalk Server 2006 R2
In the past days I have been installing ESB toolkit 2.0 for BizTalk Server 2009. In 2009 classic environment all seems to work fine but what’s the matter if I want to enjoy Exception Management Framework and ESB.Portal in 2006 R2 environment?
Hereunder my “2006 R2” machine :
• Windows Server 2003
• Microsoft .NET Framework 3.5 SP1
• IIS 6.0
• Microsoft SQL Server 2005
• Microsoft BizTalk Server 2006 R2
• Microsoft Visual Studio 2008 SP1
• Microsoft Chart Controls for Microsoft .NET Framework 3.5
Ok, let’s get started
1) install/import Microsoft.Practices.ESB.ExceptionHandling.msi
2) With VS 2008 : install powershell 1.0 in order to run ESBSource\Source\Samples\Management Portal\Install\Scripts\Management_Install.cmd
Without VS 2008 : create that 4 virtual dir with the same application pool (see Management_Install.ps1 for details) and build ASP.NET project on separate machine
3) deploy bam act and views,ecc.. with bm deploy-all -DefinitionFile:”C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bam\Microsoft.BizTalk.ESB.BAM.Exceptions.xml”
4) Now, run ESB configuration tool … ERROR!
ESB configuration tool works with SQL.DMO 10.0 that require native client 2008 e SQL Types 2008.
Excluding core components, ESB configuration tool creates :
- EsbExceptionDb and roles
- ESB.ExceptionHandlingServices (with its dedicated app pool)
- ESB.ExceptionHandlingServices.WCF (with its dedicated app pool)
We can manually set that configuration or install SQL Native Client 2008, SQL Types 2008 and SQL.DMO 2008 ( download http://www.microsoft.com/downloads/details.aspx?familyid=228DE03F-3B5A-428A-923F-58A033D316E1&displaylang=en )
5) Check the service : http://localhost/ESB.ExceptionHandlingServices/ExceptionHandling.asmx .. it works
6) Check http://localhost/ESB.ExceptionHandlingServices.WCF/ExceptionHandling.svc … ERROR
Edit web.config file adding in <system.web> section
<trust level=”Full” originUrl=”"/>
7) check http://localhost/ESB.Exceptions.Service/ExceptionService.svc .. it works
8) check http://localhost/ESB.Portal …
ERROR: The HTTP request is unauthorized with client authentication scheme ‘Negotiate’. The authentication header received from the server was ‘NTLM’.
cscript c:\inetpub\adminscripts\adsutil.vbs set w3svc/NTAuthenticationProviders “Negotiate,NTLM”
ERROR : looking at EsbExceptionDb I see that one store procedure miss. Creating it all works fine!
Remember to change Destination Location of ExceptionHandling.PipelineComponents.dll From “BizTalk Server 2009″ to 2006
Now I can enjoy ESB.Exception and ESB.Portal with 2006 R2!
WCF – 4 Tenets
TENET 1: BOUNDARIES ARE EXPLICIT
Crossing boundaries is an expensive operation because it can constitute various elements such as data marshaling, security, physical location, and so on. Some of the design principles to keep in mind vis-à-vis the first tenet are as follows:
- Know your boundaries: A well-defined and published public interface is the main entry point into the service, and all interactions occur using that.
- Services should be easy to consume: It should be easy for other developers to consume the service. Also, the service interface should allow the ability to evolve over time without breaking existing consumers of the service.
- Avoid RPC interfaces: Instead, use explicit messages.
- Keep the service surface area small: Provide fewer public interfaces that accept a well-defined message, and respond likewise with a well-defined message. As the number of public interfaces grows, it becomes increasingly difficult to consume and maintain the service.
- Don’t expose implementation details: These should be kept internal; otherwise, it will lead to tight coupling between the consumer and the service.
TENET 2: SERVICES ARE AUTONOMOUS
Services are self-contained and act independently in all aspects such as deploying, versioning, and so on. Any assumptions made to the contrary about the service boundaries will most likely cause the boundaries to change themselves. Services need to be isolated and decoupled to accomplish the goal of making them autonomous.
The design principles to keep in mind for the second tenet are as follows:
• Service versioning and deployment are independent of the system in which they are deployed.
• Contracts, once published, should not be changed.
• Adopt a pessimistic approach, and isolate services from failure.
TENET 3: SERVICES SHARE THE SCHEMA AND CONTRACT, NOT THE CLASS
Services interaction should be using policies, schemas, and behaviors instead of classes, which have traditionally provided most of this functionality. The service contract should contain the message formats (defined using an XML schema), message exchange patterns (MEPs, which are defined in WSDL), any WS-Policy requirements, and any BPEL that may be required. The biggest challenge you face is the stability of the service, once it has been published. It gets difficult to change it then without impacting any of the consumers.
The design principles to keep in mind for the third tenet are as follows:
• Service contracts constituting data, WSDL, and the policy do not change and remainstable.
• Contracts should be as explicit as possible; this will ensure there is no confusion over the intent and use of the service. Additional contracts should be defined for newer versions of the server in the future.
• If breaking service contracts is inescapable, then version the services because this minimizes the ripple to existing consumers of the service.
• Do not expose internal data representation publicly; the public data scheme should be absolute.
TENET 4: SERVICE COMPATIBILITY IS BASED ON POLICY
At times you will not be able to express all the requirements of service interaction via WSDL alone, which is when you can use policies. Policy expressions essentially separate the structural and semantic compatibility. In other words, they separate “what is communicated” and “how/whom a message is communicated.” A policy assertion identifies a behavior of a policy entity and provides domain-specific semantics. When designing a service, you need to ensure that policy assertions are as explicit as possible regarding service expectations and semantic compatibilities.
WCF – Bindings
WCF defines 9 standard bindings:
Basic binding
Offered by the BasicHttpBinding class, this is designed to expose a WCF service as a legacy ASMX web service, so that old clients can work with new services.
TCP binding
Offered by the NetTcpBinding class, this uses TCP for cross-machine communication on the intranet. It supports a variety of features (reliability, transactions, and security) and is optimized for WCF-to-WCF communication (client and service must use WCF).
Peer network binding
Offered by NetPeerTcpBinding class
IPC binding
Offered by the NetNamedPipeBinding class, this uses named pipes as a transport for same-machine communication. It is the most secure binding since it cannot accept calls from outside the machine and it supports a variety of features similar to the TCP binding.
Web Service (WS) binding
Offered by the WSHttpBinding class, this uses HTTP or HTTPS for transport, and is designed to offer a variety of features such as reliability, transactions, and security over the Internet.
Federated WS binding
Offered by the WSFederationHttpBinding class, this is a specialization of the WS binding, offering support for federated security.
Duplex WS binding
Offered by the WSDualHttpBinding class, this is similar to the WS binding except it also supports bidirectional communication from the service to the client.
MSMQ binding
Offered by the NetMsmqBinding class, this uses MSMQ for transport and is designed to offer support for disconnected queued calls.
MSMQ integration binding
Offered by the MsmqIntegrationBinding class, this converts WCF messages to and from MSMQ messages, and is designed to interoperate with legacy MSMQ clients.
Bindings : transport and encoding
