To start off, you can get all of the details and code for the “Market Sample” over here at this link.
When you have a look at this VB5 sample code from circa ‘98, you will notice that none of the objects are specifically designed to be MTS objects.
So, I have kicked off a new Virtual PC, that is running Windows 2003, as well as having Visual Studio 2005, SQL Server 2005, Indigo and VB6 installed. Wow, quite a nice mixture of technologies, don’t you think.
Anyway, about the sample code. As expected the code compiles, installed and works straight off when running on Windows 2003. The sample is composed of 4 main parts:
– a sample DB – that installed in SQL Server 2005 with little hassle and only a little tweaking– a MTS (as it was then) application, that installs on COM+ 1.5 on Windows 2003 quite easily and zero problems– a ASP scripted web – zero problems with getting it up and running– a VB client that interacts directly with the COM+ tier – which works fine with no changes
I picked this particular example due to the way it leverages a number of communication channels (both browser and client based), as well as show off different levels of granularity (i.e. Submit order is a composite of 3 finer grained method calls into the same COM+ application). When you look at the code for the SubmitOrder method, you will see it is composed of method calls to the following:
<VB code snippet> Price = Products.Purchase(Product, Quantity) Customers.Charge Customer, Price OrderNumber = Orders.Add(Customer, Product, Quantity, Price)</VB code snippet>
In my opinion this is something to bear in mind when looking at COM+/ES code and what should be exposed at the Service Boundary in the Service-Oriented world. But I will comment on that a little later in the series. So moving swiftly on…….
There are a few other aspects of the sample code to bear in mind and warrent some attention. These mainly fall into the areas of layering of logic and transactional code. When you look at the sample web site, you will see two very distinct ways of achieving the same business functionality. These are SubmitOrder1.asp and SubmitOrder2.asp.
SubmitOrder1.asp implements the core of its functionality in the following way:
<VB code snippet> Set Broker = Server.CreateObject("Market.CBroker") Broker.SubmitOrder Customer, Product, Quantity, OrderStatus</VB code snippet>
While SubmitOrder2.asp implements the core of its functionality in the following way:
<VB code snippet> Price = Products.Purchase(Product, Quantity) If Err.Number <> 0 Then bAborted = True
If Not bAborted Then Customers.Charge Customer, Price End If If Err.Number <> 0 Then bAborted = True
If Not bAborted Then OrderNumber = Orders.Add(Customer, Product, Quantity, Price) End If</VB code snippet>
For certain, both are valid approached to achieving the same functionality, but it nicely brings up the issue of how COM objects in MTS/COM+ were always implictly/automatically exposed. While this issue is not as prevalent in the ES world, for COM objects that leverage COM+ it can result in layers of granularity being broken and/or if these COM+ components were being ran out-of-process, the performance of SubmitOrder2.asp would be considerable less, as it is more chatty. There are certainly many other aspects that needs to be considered when building a Service facade, but I thought before showing some of the Indigo COM/COM+ intergation features, that it would be useful to point out that the service enablement of an existing interface maynot be the right choice, as it maynot provide the right level of granularity and may make too many assumptions about its deployment environment or it consumers. Also, as pointed out in the original article, leveraging transactions around this functionality in a coarser grained method, i.e. SubmitOrder, makes the application logic cleaner in my view.
So onto what is possible with the COM/COM+ intregration features of Indigo…. and the next posting…..
– Paul