The Virtual Enterprise

As discussed in my previous blog (The Beginning), my associates and I are going to implement a single business process with an Enterprise. This Enterprise consists of 5 systems that have defined system interfaces. We call this our Virtual Enterprise. It is virtual in the sense that it does not exist within any Corporate Enterprise, but they are real functioning applications. These applications were designed and built by my associates and I, but done so in an independent manner, as if they grew up in a real Corporate environment. Keep in mind that they are simplified versions of what one might find in a real Enterprise, but the intent is really to create a business process based off of pre-defined system interfaces. In order to provide flexibility into our Virtual Enterprise, the interfaces that each system supports can be changed simply by modifying some configuration parameters. This allows us to modify some of the restrictions of the Enterprise for determining capabilities of various SOA product suites.

Let me introduce the systems:

(1) The Alert System. This system will record information about an event. It is web based and can release the event information via JMS to a defined ActiveMQ queue. The structure of the event is specified in an XML schema.

(2) The CRM System. Here we can define employees, customers, etc. and group them together in some logical fashion. This is our people repository. This system has an RPC encoded style SOAP interface for retrieving groups of people, individuals, and the set of groups defined within it.

(3) The Scheduler. This systems provides the ability to schedule a get together (conference call, meeting, etc.). Provided some information such as number of participants, dates and times, it will provide a logical meeting place (conference call code, etc.). This application is EJB based and can be accessed via RMI.

(4/5) The Notification System. This system is responsible for notifying participants in the get together. The reason I label this 4/5 is that it is really wrapping 2 separate systems (an IVR system and an Email system). When we defined this Virtual Enterprise, we decided that participants in the get together could be notified either by email or voice. As we began to review the Enterprise and look at the Business process we were implementing, we realized that these systems were a bit fine grained for an SOA. We therefore decided to wrap these in what we call a Notification Service. This notification service will provide a more coarse grained interface to the underlying systems. This was lesson #1 for our Real World SOA. The underlying IVR system has a document literal SOAP interface and the Email system has an SMTP interface (shocking). We are allowing the Notification system to be defined using the strengths of any given SOA product we are evaluating. This is really intended to test some of the product suite capabilities for building a service as opposed to the true service enabling of existing applications.

Now that you know the systems involved, the use case is fairly straight forward (ha ha). The alert system will create an event that people need to get together and discuss. Therefore our business process has to determine what people need to get together, where they are getting together, how to contact them, manage their responses over time, and provide status back to the alert system as the process progresses. If a person is not available then contact their alternate. Sounds simple enough, but when you dig deeper there is a good bit going on here.

Subsequent blogs will provide more information as to the issues encountered along the way, potential or actual workarounds, struggles with the products, etc.

Stay tuned........