Most recent blog entries News Feed
Available at url:[http://www.codeplex.com/KeystrokeEsbNet/Release/ProjectReleases.aspx?ReleaseId=12572]
ESB.NET 184.108.40.206 Deployment Build Now available for download.
Register on this site to Download
for deployment instructions.
This will be consolidated in future releases, as will the installer.
- Added WCF Adaptor
- XSLT Manager now uses MvpXml for Exslt (instead of the older Exslt)
- IProcessMsg & related Interfaces are now all 'ByVal'
- Default to WCF Transport Adaptor when using Management Console, and uses config files ending with '.Wcf.config'
- Further WCF Configurations - MSMQ/WS-ReliableMessaging configuration
- WWF Adaptor - Sequential and State Based
- Auto-BSDL (partial) generation/population
- Dynamic WSDL generation (from Management console & service) using XSLT from BSDL
- Released more of the source code base to the Deployment Build/Codeplex
A basic WCF Adaptor for ESB.NET 220.127.116.11 has been released (with source) to Codeplex.
Whilst it only show off the basic WCF features such as basic SOAP processing as well as MTOM attachments, it shows how to integrate to ESB.NET.
WCF configuration can be changed to add Security, Reliability etc.
This is an initial release, using .NET 3.0.
The next complete build of ESB.NET will require WCF.
ESB.NET 18.104.22.168 Released
This build supports Microsoft WSE 3.0.
Key changes as a result are:
- MTOM rather than DIME attachments
- Increased WS-* compliance
- Default policies and private/internal certificates available upon request for development/testing.
Note that ESB.NET services remain unchanged as a result of the WSE version change.
Also, if you are using the ESB.NET client side components, your client code will also remain unchanged.
Serializing and Deserializing XML into Object hierarchies...One of those questions that's been asked a few times on the AusDotNet Mailing list...
XSD Schema for defining Business Services at a higher level than WSDL.
The XQuery below returns the list of records in which the BuildCmdString is zero and duration to execute is greater than 1 second.
When coupled with the up and coming BAM Services Adaptor for ESB.NET, this will provide the functionality to raise alerts on such queries.
eg. Send an alert when you get say 10 or more of these entries appearing etc.
WITH XMLNAMESPACES (
'urn:keystroke-com-au:ESB:Envelope:ESBEnvelope:Version:1-0-3' AS e,
'urn:schemas-biztalk-org:biztalk:BuildCmd2:BuildCmd2' as d
data(/e:ESBEnvelope/e:body/e:documentBody/d:BuildCmd2/d:BuildCmdString)') as Result
duration > 1000
duration > 1000
This is a short summary on how to use ESB.NET to expose your business services as SOA compliant XML Web Services.
An example of an adaptor and relevant configuration...
Why use ESB.NET to expose SOA compliant services?
The diagrams below show 2 main architectural diagrams relating to SOA based design of an Organization's internal infrastructure.
1 - The main components/services of an ESB (whether distributed or not - eg. BizTalk, webMethods are monolithic type ESB's). Distibuting these components makes the deployment more flexible. For example, if you have huge amounts of transformation loads, you
can setup a load balanced cluster for that specific task, or if you have no need for any transformation (eg. new businesses or business areas starting up with little integration work required intially) work, then you can leave that component out altogether.
Also, the various functions can be tied together as required in a pure distributed architecture. For example, the configuration below depicts a considerably featured ESB consisting of BPM/Workflow, Process Step Services (PSS) to carry out software tasks
for the Business Process Steps. Orchestrations that can be developed separately to the PSS if required - eg.PSS may be developed in .NET and orchestrations may be develped in JBPM, Windows Workflow, webMethods Modeler and BizTalk Orchestrations. They may just
be other Web Services or lower level components.
Pub-Sub may also get invoked for various PSS, and various XSLT or other services be invoked along the way.
All along, using ESB.NET as the ESB Execution Engine Core, all of the below scenarios are easily and consistently realizable, with a centralized data store for request level tracing across all ESB instances - an otherwise daunting task in the case of a distributed
ESB. The lightweight nature of ESB.NET means that multiple instances can easily be configured (via copy & paste deployment and an IIS Virtual Directory using the simple deployment scripts) to run on a single or multiple servers.
Single entry points for all services - via both the facade ESB and the single entry point used by ESB.NET for all requests, means that reconfiguring the ESB is a trivial exercise. Just copy the instance over, and change a single URL.
Even in a federated service router scenario, a simple custom router handler can be built to route requests to the various servers as desired. You can even have this custom router map to DNS if you like to make the service federation & distribution management
tied to your corporate or extranet based DNS servers.
2 - How services can be federated for enterprise-wide management yet distributed amongst appropriate Business Domains.
Partner Specific Trading, Common Information Models are out of Scope for this purpose
The reason for this post is to identify the common services layers, the relationships between the layers and the Business vs Technical perspectives most prevalent in the relevant services layers. This is an important point to identify, as
it is usually a point where communication inefficiencies between Business & IT arise.
The diagram below shows the Services Meta Model, spanning the High level Business Services down to Technology Services.
Starting from the top, the High level Business Services are the Business Reason for the Organization being. These are the value-add services of the organization offered to the outside world.
Going down the chain, the Business Services are realised through one or more Business Processes.
A Business Process in turn is usually executed via a number of manual and/or automated steps.
Process Step Services (often called Business Services by technical articles that focus on IT only) are those automated steps that are implemented via software. These services address a the unit of work required to be done by a discrete step in a Business
An Application Service is one that is not usually tied to a specific Organization's Business Process. It is a foundational component that can be used to deliver Business Value and Functionality, however is too fine grained to be of any direct Business value.
Technology Services are those services that are usually cross-cutting amongst Application and higher level Services.
The Process Step Services (PSS) are the points at which SOA based solutions deliver their value. They are the point at which
- meaningful integration is done as far as Business Functionality is concerned
- meaningful Services to the Business are delivered
- orchestration of other PSS' and potentially lower level services are done using BPEL or equivalent
PSS are basically what defines an SOA service and distinguishes it from say, any old web service. This is the level of functionality that the Business really cares about. Anything below this is not directly important and meaningful to the Business. It is
at this point that you want to reduce dependencies such that Business Processes can be easily orchestrated and changed quickly.
At this point, these services can be logically grouped into logical Business Components that are merely logical groupings of these services.
If you're a developer, this is the point that the Business wants to to talk to them. They will not usually care (apart from reasons like: out of interest, untrusting souls etc.) about anything lower level.
If you're a business person, this is the level you should go down to and define Business Level Requirements at. No lower, no higher.
These days, the Service Definition for a PSS should include:
- a sensible name, scoped as appropriate, containing the Business Service that it's being developed for
- input/output Data Definition (in the form of XSD of course, and if you want to save on overall development time, costs, confusion & increase system quality, get the Business to define the Data in XSD, not in unstructured data such as Documents, Tables,
Spreadsheets etc.). You can also use a WSDL for this and the above step.
- Message Exchange Patterns (MEP)
- SLA's, KPI's etc. and anything else relevant to the Business
- anything else you require such as Exception Management properties and behaviour, references to other documentation, summaries etc.
- a logical owner for the service
- Even though it's physically possible to develop services that skip layers, this is not recommended. Each type of service is in itself layered and can use types of its own.
- Each layer can be thought of as a Process in itself, however that's not the focus here.
The following documents explain the ESB Envelope in some detail, and explains its positive effect on a services based archtiecture.
Most recent blog entries News Feed