First of all, we have to start saying "integration server" instead of "application server." We've gotten so accustomed to saying "apps" and "app server" that we've lost the meaning. Of course, an application server serves applications. Applications were actually a "trend" at one time--a rather important trend, certainly--which has led us to this point in the evolution of software delivery: a movement away from applications and toward services. Hence, the focus shifts from application servers to integration servers--servers that integrate services.
We are at a turning point: turning away from the application as the end-to-end solution we thought it would/could be. We thought we could code it all. Code it all into one big ball.
In other words, we had, perhaps erroneously, equated the application with the business process. And so it would have been had everyone in IT adopted Java or C# or whatever...as long as it was one single all-encompassing platform/language that could do everything and support everyone., and...
Kind of a silly notion when you look back.
But I did not say that applications are going away. Often, that's what people hear when I say "turning away from applications as an end-to-end solution." Nor did I say that application servers would be going away. Application servers will continue to host applications. For this task, IBM offers you WebSphere Application Server V6; for the task of services integration, IBM offers you WebSphere Business Integration Server V4.3 or WebSphere Business Integration Server Foundation V5.1.
Perhaps the trend is more comprehensible if we use the concept of "building blocks"--the common metaphor for software components--and focus on the granularity of the building blocks.
Building blocks, components...The J2EE Framework, in its infancy, recognized the need in IT for parallel development--a stark transition from the days when a single programmer wrote a single end-to-end program. "Component providers" (an early J2EE replacement term for "programmer") specialize in very small, fine-grained pieces of software, with an eye to "decoupling" (developing components in isolation, without any built-in connectivity to any other component).
The example that comes to mind is the now ubiquitous Customer EJB (Enterprise JavaBean). The Customer EJB is an entity bean, meaning that it models a business entity and a permanent feature in the constellation of any business (the "any" is very important!). That is, it is hard to conceive of a business without customers. From the IT perspective, the customer entity is data, data about the customer, traditionally stored in a relational database. The EJB, then, is a software component that interacts with an application--a layer of indirection--as opposed to interacting directly with the database. The Customer EJB gives the application a highly configurable view of the customer.
What makes the Entity EJB customizable is that its fields, which correspond directly to columns in the customer database table, are virtualized--externalized by placing the fields outside the compiled code, in XML files referred to as "deployment descriptors." What makes this all work is that the fields in the deployment descriptor are not fields or members in the object-oriented sense, but rather abstractions in relatively simple text (all right, it is XML, which allows for the hierarchical representation of data entities in textual format). Thus, all the addition, deletion, and manipulation in terms of transactional requirements is done in a text editor by the purchaser of the component--the business. Should the business require more or fewer fields, this is quickly achieved in a text editor. The vendor-specific requirements of the business' database of choice are also externalized, and thus, rapidly configurable. This makes the choice of database vendors a business choice. This is the key: Should the business be presented with economic incentives to switch database vendors, it need not fear the underlying IT budget hit that would be incurred in a non-componentized model, which could cancel out any financial gain the database switch might afford.
But flexibility was not the sole, nor even the main, adoption point of the EJB. Not unwittingly, the J2EE community built EJB technology entirely upon the foundation of CORBA. This architecture was the product of a much larger effort by significant players in the business IT realm (IBM, for example) to design an over-reaching working set of specifications that would concretely address the needs of and thus ultimately enable the dream of e-business. The consortium founded to undertake this "Holy Grail" task is called the Object Management Group (OMG), founded in 1989. Clearly, from its title, the OMG was interested in leveraging the power of object-oriented programming in the e-business world, but it also recognized that this technology, if it were to be adopted to serve business, would need to be based on the principal tenets of business: transactional integrity and security. Thus, CORBA produced a very robust security specification, which now, after 16 years, has evolved into the industry standard Common Secure Interoperability protocol Version 2 (CSIv2).
Business-grade flexibility and business-proven security: What more could an IT architecture offer? Why wasn't CORBA/EJB, in fact, the discovery of the Holy Grail? Answer: too granular, not interoperable, flexible only in terms of database vendors, too expensive, and somewhat limited in vision. Did we really think that all business processes could be reduced to applications interacting with RDBMS?
The new components are services. There are types of services in what IBM calls its Business Integration Reference Architecture, just as there are types of components in the J2EE specification.
The most recognizable of these types of services, and the one that might do the trick of outlining the current IT "wave," is application services. Clearly, the application has now become a component itself. In this architecture, data management is separated from the application entirely, provided by information services. These two, application and information, might comprise the model, in Model-View-Controller (MVC) architecture. A third type of service is user interaction services. The key concept here is User Interaction--UI. It's the View in MVC.
Now that I've started this, I bet you're eager for the controller. It is, at one level, process services. This corresponds to the Business Process Engine in the Integration Server running the Business Process Execution Language (BPEL). This type of service coordinates the flow of other services. But it's not the only controller. Remember, in this type of architecture, the metaphor flows back and forth between the machine and the business. Thus, the services are actual business in some cases, and services interaction compares to B2B interaction, which requires different types of control: document management, protocol management, and partner management, all of which fall under the umbrella of "community integration services."
So, I hope you've become adept at shifting from components to services. But that burning question remains: So what?
Necessity is the mother of invention. The "mother" in our story came into the limelight sometime around the year 2000, when the stock market dipped below the magic number, and IT's extended holiday came to an end. This resulted in 1) much lower IT budgets, 2) the need for nimbler business, and 3) the need to accurately audit e-business processes. The "invention" was Web Services.
Web Services and its brother, Services Oriented Architecture (SOA), may be the two least-understood concepts in e-business today, even though white papers are flowing and conferences are rapidly registering. But what is the trend, really?
In a very informative white paper by D.H. Brown Associates, Inc. ("WebSphere Business Integration Server Foundation V5.1: Building and Deploying Service-Oriented Applications That Extend and Integrate Existing IT"), the authors note four trends in adoption of SOA/Web Services. I see these trends related directly to the degree of IT maturity, the degree to which IT understands the power of SOA.
The first level, the ground level, is where developers simply transform any number of applications, usually legacy applications, into Web Services. But this quick road to integration--abstracting the access to the legacy apps--is not aware of any SOA. According to the white paper, Merrill Lynch (an IBM customer), has transformed 23,000 of its legacy applications into services.
The next level is usually termed "service-oriented integration." It happens at a higher level than the first, usually involving software architects linking across business units. I think of this as the "façade" pattern, but, as I discussed above, at a higher level than, say, stateless session EJB façades. At this level, the initial work composes all the necessary providers as services to create an intuitive view. For example, a stockbroker might want to present the client with a view of the client's portfolio, which, in order to be truly rich, would have to draw from many sources--some from other segments in the brokerage, some from providers external to the brokerage, and still others from myriad bits and pieces of information best provided via a combination of legacy applications, RDBMS, etc. The white paper claims that almost half of IBM's clients are engaged in such projects and that most existing case studies of SOA adoption refer to this type of adoption.
The air is getting thinner. The next level of SOA adoption is called "enterprise-wide SOA." This is where the IT department undergoes a complete shift in culture--from the way applications are developed to the way IT professionals talk. The Enterprise Service Bus (ESB) is the driving design here. Currently, the typical implementations involve WebSphere MQ, insofar as MQ provides support for Web Services standards. However, the ESB is intentionally broad enough to extend the enterprise-wide SOA transformation to incorporate additional service infrastructures.
The last level is termed "on demand transformation." This is driven from the top, as a strategy to grow the business as quickly as possible, incorporating all of IBM's On Demand principles.
The question a business might have, after deciding which of the aforementioned transformation groups it would like to belong to, is "What will my tool (software) investment look like?" In the discussion that follows, I will focus on the integration server, not the application servers, RDBMS, CICS servers, etc. that provide the application/data functionality.
For the first level--the conversion of applications to Web Services and the hosting of those Web Services--the server investment is nominal. That's the point, actually: An integration server doesn't have to hold much or run much; it just directs traffic. For this, any number of "soap engine" servers would do the job. Some of these (e.g., Apache Axis) are robust and, well, free. Any level of WebSphere would work, including IBM WebSphere Application Server Express V6, which has exactly the same fully featured Web Services engine as the server at the other end of the price spectrum. The investment at this level is more on the programming side: Developers need to manually expose the legacy apps via J2C Connectors, which requires know-how, and produce J2EE ear files that need to run on the (application) server. Remember, though, this is not SOA--it's just simplifying the exposure of applications through WSDL. We have many Web Services, but nothing really that would be called a service in SOA.
For the second level, service-oriented integration, no more integration server power is required than at the previous level. This level of adoption is characterized by the presence of an IT architect--one with a focus on the ability of Web Services to coalesce many disparate software functions into a unified SOA service. Here, we need the same amount of J2C and Web Services conversion work as in the first level; the difference would be most visible in the parsimony of what the integration server actually hosts--a set of intuitive, clear, multi-faceted services. Now, with this "cleanliness" comes the ability to really expose a company's services to the outside world, which would lead to considerations of UDDI (most likely), a private UDDI registry, and the Web Services Gateway (WSGW). These products are part of WebSphere Application Server for iSeries Network Deployment V6.
The third level, enterprise-wide SOA, recognizes first and foremost the need for an Enterprise Service Bus (ESB) architecture. While the ESB is not an actual product, a starting point for the implementation of ESB would be the Service Integration Bus (SIBus) of WebSphere Application Server Network Deployment V6. The SIBus can tie in pieces from the second level--the WSGW, for instance, as well as something like the CICS Transaction Gateway (CTGW). The other main characteristic of the level, however, is the need/desire to incorporate asynchronous messaging into your SOA, typically using WebSphere MQ. The SIBus, specifically WebSphere Platform Messaging (WPM) incorporates SOA principles by design, insofar as it treats incoming messages agnostically; that is, SOAP messages, JMS messages, and MQ messages all come to the SIBus. The SIBus, then, is responsible for sorting the messages and directing them to the appropriate receivers.
However, it is the final level of SOA adoption, the On Demand transformation, that this article most addresses.
Such big steps require firm footing. The starting point, indeed the centerpiece, in any SOA transformation would be WebSphere Business Integration Server Foundation (WBISF). At its heart a J2EE "application" server, the Integration Server adds a runtime piece that makes it, indeed, an integration server: the Business Process Execution Container (BPEC). If you're familiar with J2EE servers, you're familiar with the idea of containers--runtime managers for particular components of the J2EE specification. The BPEC, however, doesn't manage components; rather, it manages business processes--aggregations of services. As of yet, J2EE has not recognized the idea of a process container, or for that matter, the primacy of the business process. However, there is in process a J2EE specification, Java Business Integration (currently only a Java Specification Request, JSR 208), that attempts to standardize the business process runtime.
The BPEC executes deployed service components according to an XML meta-language called Business Process Execution Language for Web Services (BPEL4WS), usually shortened to just BPEL. BPEL was proposed in 2002 jointly by IBM, Microsoft, and BEA, implementing ideas from IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG. Shortly afterward (April 2003), in order to ensure that BPEL moved in an open standards direction, the OASIS foundation created a technical subcommittee to manage the evolution of BPEL. Under this guidance, BPEL reached maturity as of WebSphere Business integration Server Foundation 5.1, although the business process Container was fully functioning in WebSphere Application Server, Enterprise Edition V5, using IBM's proprietary Flow Definition Markup Language (FDML, which is still supported in WBISF 5.1). It is important to note, however, that while other vendors of business integration servers convert the BPEL into proprietary formats for execution, WBISF runs pure BPEL with no conversions.
Business processes have differing transactional requirements. Some may execute over a short time (traditional "transactional" processing); others over a (very) long time. No less transactional than the short-lived processes, these long-running processes are interruptible (likewise, "resumeable"). An example here would be a simple real estate mortgage, which (as you might know) can continue for some years--and not statically, either. Mortgages are refinanced, used for financing for second mortgages, etc. For the long-running ones, the technical question would be where to maintain their state--that which makes them transactional. Also, since they are interruptible, an event mechanism needs to be in place, which can save the state upon interruption and read the state upon resumption. Finally, the most common type of intervention in such processes--that which interrupts the processes and resumes them--involves people.
Regarding transactionality, a short-lived business process (microflow) would adhere to the XA X/Open specifications and thus roll back everything in the event of a transactional failure. In long-lived transactions (macroflow), however, it is not always desirable to have a full rollback--you wouldn't want to "un-pay" your mortgage for the past 25 years! Transactional behavior, or rather, transaction failure behavior, is referred to, in BPEL, as "compensation." In real business scenarios, compensation can sometimes be achieved by a computer, but more often than not, the compensation involves human interaction: If we mistakenly send you a check for $1,000,000 in the mail, we can fix the error in the database, but getting the check back from you (after you've changed your name and left the country) is beyond what even the ENIAC could do!
But it's not beyond WebSphere Business Integration Server Foundation with the help of one of its components, Process Choreographer. Process Choreographer is really the runtime component in the BPEC that allows the amalgamation of anything--any J2EE component, any Web Service, any human interaction--into a business process. It's also what puts WBISF at the cutting edge of business process integration servers. With Process Choreographer, the BPEC is augmented by a set of components, plug-ins, and external APIs:
Components
- Navigator: Coordinates the calls between different activities and calls to external plug-ins
- Factory: Manages the state information of a business process with the help of a database
Work Item Manager
Creates and maintains work items for users for different activities within a business process
Plug-Ins
- Data Providers: Handle different message types sent to and from
activities - Invocation Providers: Different ways in which activities can be called
- Staff Providers: Called by the Work Item Manager to obtain a list of users
- State Observers: monitor current state of business processes
External APIs
- Process Instances: Call new instance or obtain information about existing instance
- Activities: Interact with an activity
- Work Items: Claim or complete work items
As I mentioned earlier, one of the technical requirements of BPEL, and business processes in general, is event notification. The Common Event Infrastructure was released as a technical preview in WBISF V5.1 and provided developers with the ability to create and manage business and system events. With the release of the production-ready version in V5.1.1, you can now correlate and integrate information across systems using the Common Event Infrastructure.
In terms of process execution, "activities" can be triggered by "events." These events can be produced by other activities or external elements. For example, one activity can "block" until it receives notification that another activity has (or multiple activities have) completed, as in the case of sending a complete itinerary to a traveler, which should contain confirmed hotel reservations, verified boarding passes, and an RL for your favorite car.
Another use of events is process auditing. This is one of the principle motivators for SOA--the ability to ascertain the efficiencies and failures of participants (be they human or cyber) in business processes. In WBISF, auditing can be done at a very fine-grained level to the extent that, whether an event be business related or more technical, the audit information will be useful in a comprehensive SOA analysis of the business process.
"Compensation," another BPEL concept, is handled in WBISF as a service itself. This service is implemented as a Compensation Coordinator--something along the lines of a broker--which is created at the start of a business process. The Coordinator, in turn, creates a Compensation Sphere. As its name implies, the Compensation Sphere defines the scope of the compensation. Some compensation applies globally, to all activities in the process; that is, how do we compensate if the entire process fails? This behavior would be significantly different for an individual activity, such as notifying a person of his test results. Each activity to be compensated registers a Compensation Proclet with the Compensation Coordinator. A proclet (little process) simply contains the input/output messages for the activity, which should contain all the data necessary to compensate for the activity's failure. For macroflow processes, this information is stored in the Business Process Execution Database (BPEDB).
Compensation happens when a fault is reached in an activity--you know, if something goes wrong. At this point, the Compensation Executor is created, and it calls compensating services from registered proclets in LIFO sequence, from right to left in the process editor (reverse order). Finally, this Executor marks the process instance as "COMPENSATED."
The interaction of people and processes is not recognized in the BPEL specification, but it's a cornerstone for IBM's On Demand initiative. Thus, WBISF provides additional extensions to BPEL for working with people. These are referred to as "staff activities."
When a staff activity is reached within a process, execution suspends on that instance and work items are generated for the staff instance by the Work Item Manager. A Work Item is traditionally something assigned to someone to get done by a certain time. If the Work Item belongs to you, we say you have "claimed" it (it really means that your butt is on the line if it doesn't get done!). Staff activities in WBISF are viewed as differing levels of permission (not guilt):
- Potential Owner: May claim and complete Work Item
- Editor: May view and update claimed Work Item but cannot complete it
- Reader: May view claimed Work Item
Typically, employees will log in to a Web client. WBISF comes with a Process Choreographer Web client (which may be customized to meet specific preferences). Upon logging in, users call the Work Item Manager to obtain Work Items and act upon each item, based on permissions. The GUI displays information about the current instance, and input may be specified when the Work Item completes. Finally, when the Work Item is completed, the process continues.
To handle this complex user interaction involving permissions, the staff functions interact with user registries. Staff support accommodates different user registries, including LDAP, System, and Custom User Registry (CUR). Technically, a Staff Plug-in Provider is configured, specific to user registry (LDAP, Local OS). A Transformation.xsl file is used at conversion time to resolve verbs and substitute parameters (for user queries). Included in WBISF libraries are different translation files for different user registries.
I've tried to outline the various salient features of WebSphere Business Integration Server Foundation--salient in how these features relate to or enable the SOA vision, from the beginners (Web service makers) to the riders of the wave (the On Demand transformers). I'd like to leave you with some impressions I have collected as to 1) whether it really is "the wave", and 2) whether you are on the "outside" (located beyond the peak, where the big kahunas break), the "shoulder" (the unbroken part of the wave, to the left or right of the peak; calmer, this is a great spot for beginners and intermediates), or the "soup" (also, the "inside"; the waves have already broken, nice place to just swim).
Of course, a pretty major wave indicator is that IBM has produced this massive product set, all under the umbrella of WebSphere Business Integration. Weight is added to the SOA rumblings by Microsoft, which recently published this "mission statement" for SOA:
The goal for Service Oriented Architecture (SOA) is a world-wide mesh of collaborating services that are published and available for invocation on a Service Bus. Adopting SOA is essential to delivering the business agility and IT flexibility promised by Web Services. These benefits are delivered not just by viewing service architecture from a technology perspective or by adopting Web Service protocols, but also by requiring the creation of a Service Oriented Environment that is based on specific key principles.
Hmmm. Sounds familiar. Common themes like the ESB (referred to as "Service Bus") and even the On Demand operating environment (referred to as "Service Oriented Environment") point to the significance of SOA in Microsoft and IBM. Not surprisingly, Microsoft has its own integration server:
Microsoft announced a new service-oriented architecture today as part of its latest push into the telecommunications sector.
The Redmond, Wash.-based software vendor said the latest version of its Microsoft Connected Services Framework offers management of services across a wide range of networks and devices. The company is coordinating the launch of its new server software with the 3GSM 2005 conference in France this week.
The framework consists of a new server to manage common functions of service control and aggregation; common sets of interfaces and software logic for connecting to back end systems (based on TMF eTOM and SID standards); a Web services API for adding new services; and a software developers kit and developer environment for building new services.
The significance of integration servers is summed up pretty simply in this quotation:
"The interesting and relevant question is who will own the Web services runtime?" said Miko Matsumura, vice president of marketing at Cupertino, Calif.-based Infravio. "Right now, the Java Business Integration specification [JSR 208] could potentially form the basis of a Java Community Process Enterprise Service Bus standard."
I agree that this is an "interesting" question, although I think far more relevant is the evolution of the BPEL specification, since it's BPEL that these integration servers feed on. A look at the copyright owners of the specification--BEA, IBM, Microsoft, SAP AG, and Siebel Systems--indicates to me that the success or failure of the move to integration will hinge directly on the cooperation--in addition to the competition--of these major players.
Kameron Cole is currently a Senior Learning Specialist with IBM ITES (IT Education Services), where he does instruction, onsite mentoring, and course development for the complete range of WebSphere course offerings. He is IBM certified for WebSphere Administration and J2EE Development up through V6 and Sun certified for J2EE Developer. He was a contributing author to an MC Press certification guide for WSAD V5, Developing J2EE Applications with IBM WebSphere Studio. Kameron has nine years of Java development experience, including CORBA-to-Java implementations. He is most at home on Linux or AIX.
In another life, Kameron is a cellist and currently can be heard on Jen Gloeckner’s new CD, Miles Away, on One Little Indian records.
MC Press books written by Kameron Cole available now on the MC Press Bookstore.
 |
||
 |
|
Advanced Java EE Development for Rational Application Developer 7.5 Get a look at a range of core Java EE technologies plus an in-depth description of the facilities provided by IBM Rational Application Developer 7.5. List Price $79.95 Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online