Archive for the ‘SaaS’ Category

What is an Enterprise Service Bus?

Friday, October 26th, 2007

When companies do business on a regular basis, they can save money and expedite the process by integrating their enterprise systems. Back in the 80's and 90's, we used to call this SCM or B2B.

The demand for business integration has grown to the point that vendors have created platforms for these solutions. This kind of platform is called an Enterprise Service Bus (ESB). Three of the top ESB offerings are:

All of these solutions are designed for heterogeneous environments in which services are exposed to clients of varying needs, and consumed from vendors of varying capabilities. I won't go into the differences in implementation, or try to recommend one over another. I'll just describe the space.

The ESB toolset
These solutions begin with a palette of transports, including SOAP over HTTP, email, FTP, and database polling. These transports satisfy the needs of various clients – both internal and external – who consume services according to their own preferences.

These solutions then provide a canvas for mediation and transformation. Mediation is the process of determining, based on the content of the incoming message, how a message should be routed. Transformation reformats the message for its intended target. This canvas is usually presented as a graphical workflow.

Finally, the message terminates with a consumer chosen from another palette. Standard terminals include Java JAR file, web service, and stored procedure. The message terminal may be either an internal or external service.

Network topology
ESB containers are deployed throughout the data center to handle and route messages. Only the components required by each server are deployed to that server. Messages are passed hand-to-hand, mediated and transformed along the way.

Microsoft puts BizTalk and WCF into the ESB space. However, as Dave Chappell then of Sonic Software points out, BizTalk does not have quite the topological flexibility of the other ESB solutions. A hub-and-spoke configuration does not scale as well as a bus configuration, but clustering can help ease some of the stress.

All of the evaluated ESBs are based on Java. No serious contender could be found in the Microsoft space. All include some degree of developer support via Eclipse plugins. Although none is designed to invoke .NET assemblies directly, they can all be used to call web services implemented in .NET, with the usual interoperability caveats.

The goal of an ESB is rapid integration with business partners. The palette of transports and terminals makes it possible to interoperate with partners of varying capabilities. The graphical mediation and transformation interfaces make it easy to change business rules on-the-fly without requiring development resources. An ESB is overkill for many enterprise problems, but when you need it, you need it.

Well Enabled Services

Thursday, September 27th, 2007

As part of my current software-as-a-service project, I've been investigating Microsoft's Connected Services Framework (CSF). This is Microsoft's answer to the service management problem. Service management is an issue in any IT department, but it is especially important when those IT services are offered to your customers.

At the core of CSF is the well-enabled service (WES). This is a web service with additional interfaces. These interfaces provide support for:

  • Discovery
  • Provisioning
  • Health
  • Utilization

Web services in general define a mechanism for discovering (WSDL) and consuming (SOAP) the service itself, but offer no management assistance. A WES adds these missing management interfaces.

Discovery
WSDL provides for the consumers of a web service to discover its capabilities. But a WES adds discovery of resources managed by that service. This set of resources differs from one service to the next. For example, an email service would manage mailboxes. The WSDL would tell the consumers of the service that they can check their email, but the WES discovery interface tells the IT technician that he can create and delete mailboxes.

Provisioning
In a single-tenant situation, the IT technician provisions services on behalf of his users. In our email example, this means that he would create a mailbox when someone is hired, and delete it when they are fired. In a multi-tenant situation, however, manual provisioning doesn't scale. Instead of the service provider handling every provisioning request manually, he would prefer to automate the task and put the power in his customer's hands.

Most services are not designed for multi-tenancy. They were built to solve a specific business problem. The burdens of scalable IT were probably not even considered during their design and construction. And even those that were designed for multi-tenancy have their own application-specific provisioning interface.

The WES provisioning interface is a small but important step toward a scalable IT solution: it gets us thinking about multi-tenancy during the design phase, and it gives us a common interface to implement. Granted, that interface is extremely weak (the ProvisioningRequest message has one string field: Data), but it's a start.

Health
A single-tenant IT technician can answer his user's support questions by using an application-specific interface to check the health of their resources. But in a multi-tenant environment, that doesn't scale. The customers should be able to check on the health of their own resources.

The WES health interface provides an automated mechanism to query the status of a resource. With this, a user could see, for example, whether their mailbox is online or offline, whether they have had any failed login attempts, and whether they are approaching their quota. These particular health metrics are specific to email, of course. Each WES advertises its own available metrics through the discovery interface.

Utilization
The single-tenant service has an on-going operational cost, regardless of utilization. The consumer of the service has already paid for it. The multi-tenant service, however, is paid for by the service provider. The service provider must ultimately bill the consumer for its use. One way to do this is to bill based on utilization.

The WES utilization interface allows a billing system to subscribe to usage events. When a billable event occurs -- exceeding a mailbox quota, for example -- the billing system is notified, and the invoice is sent.

Unfortunately, this subscription model creates several race conditions. The WES must be started before the billing system so that it can accept subscriptions. If the WES is ever restarted, the billing system must know to re-subscribe. And if the billing system hasn't subscribed when a billable event occurs, that information is lost.

Here's my opinion
Well-enabled services are a good start. Unfortunately, they are just a start. They give us a defined entry-point for provisioning, but do not prescribe a format for those messages. This means that tool support will be limited to routing messages, since generic tools cannot be built to generate or understand service-specific messages.

Furthermore, well-enabled services are built on unreliable technology. HTTP web services do not guarantee delivery. This may be acceptable for certain services, such as checking email, but it is not acceptable for provisioning requests and billable events. Lost bills means lost money.

More information
Microsoft and British Telecom have created the Connected Services Sandbox: a listing of well enabled services. They have posted an excellent article on Building a Well Enabled Service. This goes into much better detail, describing what a WES is, who should build them, and how to do it.

Microsoft's landing page on the Connected Services Framework is mostly executive-level propaganda. I'd recommend starting at their Communications Sector Developer Center for more relevant information.

What is Active Directory?

Wednesday, September 26th, 2007

Active Directory is Microsoft's identity solution. It is part of Windows Server, and controls access to all the resources (computers, shared folders, printers, etc.) in a network. Active Directory is likely an important part of any software-as-a-service offering. Here are the things it contains.

Domains
A domain is the container and namespace for all objects in the directory. Active Directory cooperates with the DNS server built into Windows Server, so the AD domain is synonymous with the DNS domain.

Organizational Units and Groups
Both organizational units (OUs) and groups are ways to collectively manage rights. They each describe a collection of users, computers, or shared objects (like folders and printers). You can define rights and policies at either the OU or group level, and those rights and policies apply to all members.

The difference between an OU and a group is one of ownership. An OU owns the objects it contains. It is a strict hierarchy. A group, however, is a loose collection. An object can be a member of more than one group, but it can belong to at most one OU.

OUs typically break a domain down by region or department. All objects in the OU are typically geographically located, served by the same IT team, and under the same management. Groups, on the other hand, typically break a domain down by role. All objects in the group serve the same function, regardless of their OU.

Trees and forests
In AD vernacular, you'll hear people talk about trees and forests. Besides inspiring obvious puns about not being able to see things, these terms can cause confusion. There are no explicit objects in AD called "tree" or "forest". These are just concepts for how domains relate.

A domain has a dotted distinguished name -- a.k.a. a DNS name. For example, I have a domain called "mallardsoft.com". In my virtual lab, I defined another domain called "mlp.mallardsoft.com". Since they share a common root, these two domains together form a tree. Any domain that ends in "mallardsoft.com" is part of this tree.

Domains deeper in the tree implicitly trust those higher up. So "mlp.mallardsoft.com" trusts "mallardsoft.com". But you can establish a trust relationship across trees. When you do, the conglomeration of trees defined by the web of trust is a forest. The domain at the center of this web of trust is sometimes synonymous with the forest itself.

Best Practices
The best advice I've found related to Active Directory is to keep it simple. Always start with just one domain, until you are compelled to create more. Don't define a domain tree to represent regional or organizational divisions; that's what OUs are for. And don't join domains into a forest unless you really need to merge two disparate trees.

Don't go crazy creating many nested OUs or groups. You don't need to represent your entire org chart in AD. Just define a few high-level departments in which members tend to share resources, and roles in which member tend to share responsibilities.

For software-as-a-service, create an OU specifically for your users. Don't let them get mixed up in your internal OUs. Users and employees can peacefully coexist within one domain, but they should never occupy the same OU.

activedirectory.png

Virtual Network in Microsoft Virtual PC

Wednesday, September 12th, 2007

For various reasons, I find myself needing to switch from VirtualBox to Microsoft Virtual PC. Virtual PC lacks the easy snapshot feature, but it has one significant advantage. Everyone else on the project is using it. This makes it possible to share virtual hard drives with each other, something that is surprisingly difficult with VirtualBox. And these virtual hard drives can be hosted with Microsoft Virtual Server for staging in the integration environment.

The virtual network that I built in VirualBox did not port to Virtual PC or Virtual Server. Virtual Server has no NAT capability, and Virtual PC's NAT does not let the VMs talk directly to each other. I had to find a new way to accomplish the same result. Fortunately, with a little help (OK, a lot of help) from Virtual PC Guy (on loopback, NAT and ICMP), I got it working.

Here's his solution
Go to Ben's blog to follow his detailed instructions on installing the Microsoft Loopback Adapter. Please note that in Vista you have to switch control panel to the classic view in order to find the Add Hardware icon. And the wizard is slightly different: manually select, network adapters, Microsoft, Microsoft Loopback Adapter. When it gets installed, it creates a new adapter called "Local Area Connection 2". I renamed this to the more meaningful "Virtual Network".

In Vista you can change the IP address of the loopback adapter, which according to Ben is impossible in XP. Just go to the Network Connections page. (The simplest way I've found to get there is to open the menu formerly known as Start, right-click Network, properties, and then "Manage Network Connections".) Once there, you can rename the connection or change its properties. I set my virtual network's IP to "10.123.1.1" and the subnet mask to "255.255.255.0" to avoid any routing collisions.

In Virtual PC, open the network settings and set Adapter 1 to "Microsoft Loopback Adapter". Then start up your VMs and configure their IP settings. My VMs are configured thus:

  • MLP-AD (active directory and DNS)
    • IP: 10.123.1.100/255.255.255.0
    • GW: 10.123.1.1
    • DNS: 127.0.0.1
  • MLP-WSS (SharePoint)
    • IP: 10.123.1.101/255.255.255.0
    • GW: 10.123.1.1
    • DNS: 10.123.1.100

The loopback adapter does not respond to ICMP pings from within the VMs, so you can't ping your default gateway to see if your configuration is working. But you can ping the VMs from each other, and you can ping machines outside of the virtual network.

Install Windows SharePoint Services in account creation mode

Wednesday, September 5th, 2007

The installation of Windows SharePoint Services (WSS) is by no means straight-forward. WSS reaches its appendages into Active Directory, SQL Server, and IIS. You have to dance from one to the next in order to make it all work together. And any error messages you run into won't tell you how to fix the problem. It will just leave you scratching your head and running to Google. Hopefully such a search brought you here, and together we can find a solution.

I highly recommend that you get a book to help you with the process. I'm using Jim Buyens' Microsoft Windows SharePoint Services Inside Out from Microsoft Press.

The following steps assume that you have created a virtual network having two machines. Mine are called MLP-AD and MLP-FULLSTACK. My domain has the short name MLP, and the long name mlp.mallardsoft.com. Please make the appropriate changes for your configuration.

Prepare Active Directory
In account creation mode, WSS creates user accounts in Active Directory. We need to set up a place for those accounts to live, a domain user with permission to create them, and an owner to start us off.

On MLP-AD, create a user account named SharePoint_admin with a password that cannot be changed and never expires. Also create a domain user to be the owner of your sharepoint site (ex. MySiteOwner) with the same password lifetime. Finally, create an organizational unit called “sharepoint_ou” for the new user accounts that WSS will be creating. Right-click this new organizational unit and delegate control to the SharePoint_admin user.

Then switch over to MLP-FULLSTACK and grant SharePoint_admin permission to log on as a service. This is located conveniently in "Administrative Tools", "Local Securty Policy", "Local Policies", "User Rights Assignment". Double-click "Log on as a service" and add the SharePoint_admin account.

Prepare SQL Server
Account creation mode requires SQL Server 2003. It cannot run in MSDE. So go to the SQL Server Management Studio and add a login for SharePoint_admin ("Security", "Logins", right click, "New Login"). Be sure to use the full name including the domain (such as "MLP\SharePoint_admin"). Check the "dbcreator" and "secirityadmin" roles.

Prepare IIS
To keep the SharePoint site separate from the default web site on MLP-FULLSTACK, we want to create a new virtual host. Start by creating an A record entry in the DNS server. On MLP-AD, open the DNS management console from Administrative Tools. Open the “Forward Lookup Zones” folder, right-click “mlp.mallardsoft.com”, and select New Host. Set the host name to mysite, and the IP address to 192.168.0.3.

Now back on MLP-FULLSTACK, open the IIS Manager from Administrative Tools, and drill down to the Web Sites folder. Right-click the folder and select New Web Site. Using the wizard, enter the description “MySite”. Set the host header to “mysite.mlp.mallardsoft.com”. Set the path to “c:\SharePoint Sites\MySite”. Allow permissions to read, run scripts, and execute on this site.

Install WSS
At this point, you are ready to install Windows SharePoint Services on MLP-FULLSTACK. Do not use the “Add Role” feature in “Manage Your Server”, as this will only perform an MSDE based installation. Instead, unpack the installation files from your MSDN disk and run "C:\Program Files\STS2Setup_1033\setupsts.exe". Select the “Server Farm” option. This installer takes a while and doesn’t really let you know that it’s working, so be patient. When the installation is finished, it launches a configuration page.

Create the new application pool
Using the configuration page that appears after the installation, create a new application pool called SharePointAdministration. Use the “MLP\SharePoint_admin” account that you created earlier, and select the NTLM security configuration. If you receive the error System Error 1057 while trying to query service “SPTimer”, then you forgot the domain name (MLP\…).

When prompted to do so, type iisreset at the command line. Then click OK on the config page. At this point you will be prompted to create the configuration database. Close the browser now, as you need to do this from the command line.

Create the configuration database
From a command line, change to the directory “C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN”. Run the following command:

stsadm -o setconfigdb -ds MLP-FULLSTACK -dn sharepointconfig -adcreation -addomain MLP -adou sharepoint_ou

This creates a database called "sharepointconfig" on the server MLP-FULLSTACK. It uses Active Directory account creation within the domain MLP and the organizational unit "sharepoint_ou".

Now specify an email server for sending invitations to new users. This should be an internal SMTP server, since you cannot configure authorization. It will have to be an open relay.

stsadm -o email -outsmtpserver smtp.mycompany.com -fromaddress admin@mycompany.com -replytoaddress admin@mycompany.com -codepage 1252

Create a SharePoint site
And finally extend the mysite virtual server to add SharePoint services. This also creates a new application pool for the site called “MySiteApplicationPool”, and a content database called “mysite”. This step may hang. If so, hit Ctrl+C and continue.

stsadm -o extendvs -url http://mysite.mlp.mallardsoft.com -ds MLP-FULLSTACK -dn mysite -apcreatenew -apidname MySiteApplicationPool -apidtype configurableid -apidlogin MLP\SharePoint_admin -apidpwd "SharePoint_admin password" -ownerlogin MLP\MySiteOwner -owneremail mysiteowner@mycompany.com -exclusivelyusentlm

If you receive the error message “The virtual server was extended with Windows SharePoint Services, but the following error occurs in creating the default site…”, then you will have to fix the problem and manually create the default site:

stsadm -o createsite -url http://mysite.mlp.mallardsoft.com -owneremail mysiteowner@mycompany.com

Set an administrator group
Access your new SharePoint site by browsing to http://mysite.mlp.mallardsoft.com. If you get the error message “Access denied. You do not have permission to perform this action or access this resource”, then you will have to set an administrator group. This can happen if you install WSS while logged in as a local administrator rather than with a domain account. Go to the SharePoint Central Administration page and click “Set SharePoint Administration Group”. Enter “MLP/MySiteOwner” and press OK. Now that can access the site.

Virtual network

Friday, August 31st, 2007

Configuration of the SaaS virtual lab continues.

I’ll be running Windows SharePoint Services in active directory account creation mode. In this mode, the SharePoint users will have Active Directory accounts instead of Domain accounts. To do this, AD has to be running on a machine other than the one hosting SharePoint Services. So I set up a second VM called MLP-AD.

I created a domain in Active Directory called mlp.mallardsoft.com. This domain is not a true entry in the mallardsoft.com DNS server. Instead, MLP-AD is running a DNS server of its own. It has an A record mapping mlp.mallardsoft.com to its own IP address. Because of these changes, MLP-AD needs a static IP address. Rather than try to convince the network admins to allocate an address for my virtual machines, I took the VMs off of the corporate network.

In VirtualBox, I created a second host interface for the second VM. But instead of bridging the host interfaces to the Local Area Connection, as I had previously, I bridged them to eachother. This creates a new Network Bridge connection, which you will find has its own IP address. The default happens to be 192.168.0.1, which works just fine for my purposes.

I’ve given each of the VMs a static IP addresses within this subnet (192.168.0.2 and 192.168.0.3) and configured them to use 192.168.0.1 as a default gateway. Then I enabled internet connection sharing on the Local Area Network to give the VMs access the outside. However, since the host's connection is acting as a NAT router, the VMs aren't visible from the outside.

Now MLP-FULLSTACK uses 192.168.0.2 as its DNS server, and can resolve the name mlp.mallardsoft.com. This allows MLP-FULLSTACK to join the domain.

Virtual Network

VirtualBox vs Microsoft Virtual Server

Thursday, August 30th, 2007

I’ve installed VirtualBox as an alternative to Microsoft Virtual Server. I’ve set up a VM using the same parameters as the MVS VM (512 MB memory, 10 GB hard drive). And I've installed the same guest OS (Microsoft Windows Server 2003).

This is a much more accessible solution. Everything appears within one simple UI. You can create, manage, and run multiple VMs from one list. No running within the browser, and no ActiveX control.

As compared to Microsoft Virtual Server, VirtualBox offers all the same features (mounting ISO images, mapping network adapters, etc.), but also adds audio and USB support. And it puts snapshot capabilities right up front on its own convenient tab. To make a snapshot in MVS, you have to copy the virtual hard drive file to a different folder and manage it separately.

There is one extra step you need to take to give your virtual box access to – and make it accessible from – the outside world. Whereas this is a combo-box in MVS, you need to manually bridge network connections for VirtualBox.

First you will need to change the virtual network adapter. When you power down the VM, the configuration links become accessible in the VirtualBox Details tab. Click “Network” and in the “Attached To” combo box choose “Host Interface”. Hit the “Add” button in the “Host Interfaces” list and create an interface called “VirtualBox Host Interface 1”.

Next you will need to bridge this virtual adapter to your physical adapter. In XP, right click on “My Network Places” and select “Properties”. In Vista it’s conveniently hidden from you. Open the control panel and search on “Network”. Click on “View Network Connections”. You should now see all of your network adapters, including “VirtualBox Host Interface 1”. Select both your “Local Area Connection” and this virtual interface, right-click, and select “Bridge Connections”.

Start your VM again and it will now appear to be on your network.

Besides this additional networking hassle, the tradeoff between VirtualBox and Microsoft Virtual Server is that MVS looses the simpler UI and comprehensive device support in exchange for remote administration via its web interface and ActiveX control. It is designed primarily for headless servers, where remote administration is more important than audio or USB.

For my purposes, VirtualBox makes for a better lab experience.

VirtualBox running Windows Server 2003 in Vista … on a Mac

Server stack in a box

Wednesday, August 29th, 2007

I've installed a virtual machine on my laptop so that I can work with the Microsoft server stack. Here are the steps I went through, just in case you want to follow along.

You will need:

  • Windows Server 2003 install disk
  • Install disk for SQL Server, BizTalk, SharePoint, and any other server components you want to test.
  • Internet connection
  • 10 GB free hard drive space
  • At least 1 GB memory

I recommend that you get an MSDN subscription for all of the install disks that you need. Be sure to request a license key for Windows Server 2003. Click on Certified Partners Downloads and Product Keys. Drill down to Windows Server 2003 under Operating Systems in the left-hand panel.

Download Microsoft Virtual Server 2005 R2 SP1. The download requires a Live ID and registration, which is mildly annoying. An MSN or Passport login will work, too. Fill out all required fields if you want your download.

After you complete the install, you can access the administration interface at http://<your machine name>/VirtualServer/VSWebApp.exe?view=1. It only works in IE, not Firefox. And you need to specify your machine name, not “localhost”.

In the admin page, create a new virtual machine. I chose the name “FullStack” because I intend to install the full stack of services on this box. Choose a reasonable amount of memory and maximum hard drive space. I chose 512 MB of memory and 10 GB max hard drive, which is a bare minimum for my purposes. The virtual drive file will dynamically grow to this max, but I don't want it getting out of hand. In the future I may need to up these numbers. Also I’ll try moving the virtual hard disk to an external drive so I can keep the notebook drive clean.

You'll want to attach your virtual network adapter to your real network card so that other others can gain access to it. Simply choose your NIC in the drop down. I chose my wired vs. wireless NIC just to be safe. The Internal Network selection should allow you to access the VM from the host machine only, but I couldn't get that to work for me.

Once your VM is created, click on the screen thumbnail to remotely control it. The first time you do this, you’ll be prompted to enable the Virtual Machine Remote Control (VMRC) server. Just check Enable and hit OK. You will then be prompted to install an ActiveX control. Once you do, you should be able to see your brand new box prompting you to “Reboot and Select proper Boot device or Insert Boot Media in selected Boot device”. This was so cool, I just had to take a picture.
Virgin VM

Now you can install the guest OS. I have ISO images for the install disks rather than physical media. So I changed the CD/DVD settings for the VM. First, copy the ISO images to the VM folder in “C:\Users\Public\Documents\Shared Virtual Machines”. Then, remove the existing “Primary Channel” attachment by selecting it and checking “Remove”. Add a new one by selecting the *.iso file from among the known ISO images. Now the ISO image will appear to be a physical CD within the VM. You can switch to a different ISO image at any time – even while the VM is running – by going back to the CD/DVD settings.

I'm going to see how far I get with this configuration. I'm also considering VirtualBox as an alternative to Microsoft Virutal Server. It would be nice to get out of the browser.

New job, new tools

Tuesday, August 28th, 2007

After six years as a corporate product developer and architect, I have gone back to my roots as a consultant. During my year at Handmark and my five years at Radiant Systems, I've met some great people and grown quite a bit. However, I missed the opportunity to serve different clients and use a variety of tools.

I have joined SSG, the company for which I have been working part time for the past three months. While that side project is nearly complete, they need some architectural help on a much larger software-as-a-service project. So I am researching SaaS and the Microsoft server stack designed for this kind of project.

On the SaaS front, I found this excelent overview: Architecture Strategies for Catching the Long Tail. This article actually has little to do with the long tail, other than that long-tail services depend upon outsourcing to be viable. The article describes a maturity model for SaaS, and guides the reader to the best architectures for each of the four target levels. I can immediately see that Radiant's SaaS (Aloha Enterprise) was at level 2, and that it probably needs to migrate to a level 4. The article outlines at a high level how to get there, and what barriers you will have to overcome.

I still have to do some anaysis to determine what maturity level this new project should target. At first glance, it appears that level 3 will be appropriate. I'll have to learn more about their operations and expected growth to make a proper assessment.