Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » .NET Framework »
The Joy of Building with BizTalk Server 2004
|
The Joy of Building with BizTalk Server 2004
Microsoft’s launch of BizTalk Server 2004 provides the final piece in ‘the re-use jigsaw’ of modern development. This article will discuss this in more detail but first…
If we were to liken software development today to engineering and household product development some 200 years ago we can see we have an interesting parallel. Before mass production everything we needed was pretty well handmade. In fact not only was it handmade but a high degree of skill was required. Specialists abounded, potters, blacksmiths, coopers, cobblers, and tailors all providing specific products.
With the Industrial Revolution came mass production and with it cheap one or two sizes fits all approach. Take for example the first Ford motor car – 1 model, 1 colour but at the right price point. Software development is still at that pre-Industrial Revolution state where most software solutions require ‘craftsman’ like skills in specific areas to deliver results. We have had the first attempts at ‘mass production’ with various code generators and so called custom application generators but none have made the impact predicted. So where does thus leave us in moving solution development forward? Well the answer, I believe, is in “re-use” by that I don’t just mean code snippets!
“Re-use” – the developers dirty word
Re-use, and in particular, Code re-use has been the bane of many a development team and more often than not has ended up as a dirty word. It is the desire of many a development manager to have that large library of re-usable code just waiting to be included in the project to maximise profit, reduce risk and meet delivery times. But the problem has always been the same:
• Writing reusable code always takes more time than writing single use code – it needs to be configurable and address many problems not just the one at hand
• Even with the best will in the world the code may not ever be re-used!
• Coding for re-usability in a project means we are coding beyond the customer requirements so who will pay?
• In order that re-use can occur functionality needs to become generalized. This has not usually been easy to achieve at a code level.
Moving on from code re-use we enter the world of object or module level re-use. This still has a lot of the same traits as previously seen at a code level except we can start to inject some patterns into our solutions such as common logging and error handling, UI control and database access. At this level we do get the library of useful stuff or at worst case the framework starters. Moving on today and the future re-use grows up and we can consider using and re-using applications as our building blocks. Enterprises have many applications serving a number of varied functions and furthermore other enterprises have applications providing many differing functions so let’s re-use them. An interesting point here is we have now moved the paradigm from component based development to service based development. I have tried on a number of occasions to explain and relate both components and services but not to my complete satisfaction. Recently I cam across this on Clemens Vasters blog :
The term component is a development and deployment concept and refers to some form of compiled code. A component might be a JVM or CLR class, a Java bean or a COM class; in short, a component is any form of a unit of potentially reusable code that can be accessed by name, deployed and activated and can be assembled to build applications. Components are typically implemented using object-oriented programming languages and components can be used to implement services.
A service is a deployment and runtime concept. A service is strictly not a unit of code; it is rather a boundary definition that might be valid for several different concrete implementations. The service definition is deployed along with the components that implement it. The communication to and from a service is governed by data contracts and services policies. From the outside, a service is considered an autonomous unit that is solely responsible for the resource it provides access to. Services are used to compose solutions that may or may not span multiple applications.
At this point we must remove our code geek hat and think business solution. Let’s pose a question – “How can I deliver a simple Request For Proposal fulfilment system for my company when all the information I require is spread across a number of systems?” My answer is use a Service-Orientated Architecture (SOA) utilising BizTalk Server 2004 at its centre. I will now show how!
Service-Orientated Architecture based on BizTalk
So let’s define SOA: it is an architecture for linking resources on demand. In an SOA, resources are made available to other participants in the network as independent services that are accessed in a standardized way. This provides for more flexible loose coupling of resources than in traditional systems architectures.
So how do we standardise the way we access the services? Well the answer for me is two fold: Web Services and BizTalk Server 2004. Where possible we expose our applications as web services. In fact we expose particular services provided by our applications as web services and we then add business process and logic using BizTalk Server 2004 in the form of orchestration. This is BizTalk Server 2004’s prime role in the SOA.
You can, of course, build an SOA without orchestration – the high level logic can be created by hard coding sitting on top of the lower-level services - but orchestration allows the SOA to change rapidly to meet the ever-changing business requirements. In addition, where it proves difficult to expose applications directly as web services, we can utilise BizTalk Server 2004 to do the job of providing these services as web services for us.
So let’s continue looking at our solution. Figure 1 shows the simplest SOA solution I can come up with. Put simply we have a Microsoft Office 2003 Infopath form connected to a CRM system. The purpose of the solution is to provide a desktop based customer lookup without have to deploy CRM clients. The CRM system exposes a couple of services that the form can use for this purpose.
These are:
• Get Customer Details
• Get Customer Delivery Details
From a solution point of view this sort of information is normally sourced from a database that would have to be maintained for this new solution or else we would have to try and develop interfaces and add a module on. But with the SOA paradigm we simply call the service we need.
Figure 1 – Basic Services based on CRM
Figure 1 shows how an application can be treated as a service – this is as simple
Ok, this doesn’t move us far from simple web service us – where it gets more interesting is when we expand the solution. We want to generate a desktop based ‘Request for Proposal’ document based on information cleaned from our back office.
1. We will get customer information from our CRM
2. We will get product information from our ERP
3. We will get discount or maybe campaign data from the Commerce system
For simplicity we are going to use Microsoft Office 2003 Infopath product as our desktop UI. Not only does this product allow the ‘rapid’ development of complex forms based but it is a consumer of web services.
The CRM and Commerce system both expose their services through web services. Unfortunately our ERP doesn’t. We have a number of solutions for this problem. Custom develop a web service interface for the ERP or interface to the system via a middleware product such as BizTalk Server 2004. As there is a need to apply logic to the process of pulling back ‘discounted’ pricing for our product requests the second approach was adopted.
Figure 2 – An SOA solution for the RFP requirement
Going back to Figure 1 – we have already seen a couple of useful services from our CRM. As long as the data is in the correct format we can consume these directly from our Infopath form. But what if we need a totally different format we need to transform the data received from the service. The important thing is, though, we are thinking at a service layer.
Figure 2 shows a very simplified overview of our approach to the solution. Using the services already provided by our CRM web service we now add a layer using BizTalk Server 2004. We could of course go straight to the CRM web service itself but this may not provide the actual result we want. For instance we could be in the position where the company stretches over a number of regions each with its own regionalised CRM so we can put logic in the BizTalk Server 2004 layer that selects the correct CRM to get the data from. We could need the data at the application – in this case Infopath - in a different format therefore we can transform the data into a different format than that from of the CRM. Finally we will probably upgrade/change the CRM system at a later date so loosely coupling the CRM to the application via BizTalk Server provides an on going solution for this issue.
Our solution now includes the ERP and Commerce aspects of the problem. For this example consider the following requirement:
1. A call from our Infopath form gives the customer name and a product code.
2. What is expected back is data including the availability of the product and the ‘discounted’ cost.
3. ERP doesn’t have web services
4. Most of the data we require resides in the ERP but the crucial discount data is held in the commerce application
Our BizTalk based solution satisfies the requirement as follows:
1. Using BizTalk custom adapter tied into the ERP API we can fetch the product data – we now have a product service! Furthermore BizTalk Server 2004 allows us to then expose the result as a web service.
2. The data recovered from our ‘product service’ can now be modified by the discount value recovered from Commerce applications ‘get discount’ service.
3. This whole business process is carried out by BizTalk orchestration and exposed to the Infopath form as a web service ‘get discounted product and availability’
Effectively we have built a new service by using an aggregation of data from a number of other services. Furthermore we have ‘re-used’ existing services and added other logic around them to extend their use.
BizTalk Server 2004 is an exceptionally flexible and powerful tool for constructing SOA solutions. Out-of-the-box it provides facilities for consuming Web services and exposing its orchestrations as Web services - in this way we can build services from other services. Moreover, its adapter framework enables Web service facades to be created for legacy applications and data sources such as the ERP system in this example.
We can take the solution a further step on and consider our SOA over not one but multiple companies.
Figure 3 – Cross business SOA
In figure 3 I have added a ‘Products’ server from Acme Inc into the picture. Extending our example a little further we could, for instance, need an availability quote for a product not shown as held by us in our ERP. A simple service provided by the product supplier would allow an additional step of getting that availability and adding it to our RFP. This is the power of not only BizTalk but SOA.
Summary
I started this article by comparing software development with engineering just before the industrial revolution and described how far from the position where we can ‘mass produce’ software solutions. What I surmise that whilst this is true, SOA and BizTalk’s part in the engineering of solutions based on the architecture have taken us a step closer to reaching that position. Not only can we expose internal applications as services but we can also utilise those of other organisations in our composite solution.
BizTalk Server 2004 not only provides the plumbing for SOA but also adds the logic to make it really work.
|
Responses
|
| Author: critic 29 Dec 2004 | Member Level: Bronze Points : 0 | That is a great one, Andrew!
We are looking forward to see more from you.
| | Author: Gnana Prakash 02 Feb 2006 | Member Level: Bronze Points : 0 | Hi Andrew,
Your article is looking good.
The figures are not shown in your article. Please verify it .
Regards,
Prakash.
| | Author: Sreekumar Menon 23 Sep 2006 | Member Level: Bronze Points : 0 | http://www.server-management.co.uk/index.php?option=com_content&task=view&id=287&Itemid=57
|
|