PHP Benchmarking

Benchmarking Slides from PHPBenelux 2011

by Paul Jones

BizTalk Adapters - The Scheduled Task Adpater: Receive Location

BizTalk Adapters - The Scheduled Task Adpater: Receive Location

10 interesting PHP Blogs

10 interesting PHP Blogs

C# Code Sample: Hashing Data

C# Code Sample: Hashing Data

C# : Encryption & Decryption Application

A generic encryption & decryption class wrapper for C#

XCrypt - encryption & decryption class wrapper

Orchestration VS Schemas as a Web Service (BizTalk Web Services Publishing Model)

BizTalk Web Services publishing wizard offers two options: Publish orchestrations and Publish schemas as a web services. What is the difference and when should we prefer one to another? Below are some practical considerations that may help one to decide.

Publishing Orchestrations

Pros:

• Short development cycle, well suited for agile iterative development
• Easy to use and understand by developers
• No special XML Schema, WSDL skills needed

Cons:

• Limited control over the message schema, no flexibility to optimize it
• Poor collaboration model - can't share service contract among parties until it's stable
• Weak interoperability control
• Encourages bottom-up design approach, as the result is a high chance of tight coupling services and overall poor solution design that doesn’t scale and is not truly “service oriented”

Publishing Schemas

Pros:

• Encourages top-down contract-first approach that enables designing true service oriented solutions
• Emphasis on message helps designing better messages aligned with business processes
• Gives control over the message schema
• Opens opportunity to share service contract among participants in collaborative development
• Potential to create more interoperable services
• Possibility of optimizing service performance
• Isolated services development and easy iteration over stabilized schema

Cons:

• Requires skilled developers who know XML Schema, understand WSDLs and appropriate tools
• Longer initial design phase, difficult to conduct iterations before schema is stabilized because of manual work involved
• Poor implementation of WSDL generation, manual tweaking of service description required
• Limited toolset to support development process

Summary:

Publishing schemas as web services is the choice to consider when:

• Designing top-down contract-first global scoped services (for example, consumed from outside of the enterprise boundaries, i.e. B2B)
• When designed service should follow existing or given service contract, for instance some standard industry schema
• No or little control over service consumers, change management is difficult or impossible
• Large complex solutions with high number of dependencies
• Collaborative development involves multiple parties sharing the same service contract
• Interoperability is a major concern
• Project timeline allows time for thorough messaging schema design
• Developers available with XML Schema and WSDL skills

Publishing orchestrations is a way to go when:

• Implementing simple solutions with small number of dependencies when we have control over both consumer and service endpoints
• Rapid prototyping, proof-of-concepts, service stubs
• Developing local scoped services, when collaboration is not an issue
• Don’t care much about interoperability
• No skilled XML Schema, WSDL developers available

Upload files with HTTPWebrequest (multipart/form-data)

Upload files with HTTPWebrequest (multipart/form-data)

http://stackoverflow.com/questions/566462/upload-files-with-httpwebrequest-multipart-form-data

BizTalk: Changing the Outbound Namespace

I run into an interesting requirement to make sure my outbound xml file uses a specific namespace prefix. Since the BizTalk mapper always generates xml documents with the “ns0″ prefix I wasn’t quite sure how to accomplish this and posted my question to the microsoft.public.biztalk.general newsgroup. It turns out to be very straight-forward to accomplish.

Full Article

Exposing a WCF Service With Multiple Bindings and Endpoints

Windows Communication Foundation (WCF) supports multiple bindings that allows developers to expose their services in a variety of ways. What this means is a developer can create a service once and then expose it to support net.tcp:// or http:// and various versions of http:// (Soap1.1, Soap1.2, WS*, JSON, etc). This can be useful if a service crosses boundaries between intranet and extranet applications for example. This article walks through the steps to configure a service to support multiple bindings with Visual Studio 2008 and the .Net 3.5 framework. For those that want to jump directly to the sample solution it can be found at the end of this article.

Full Article