Bick Group

David Linthicum

Subscribe to David Linthicum: eMailAlertsEmail Alerts
Get David Linthicum: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: RIA Developer's Journal, SOA & WOA Magazine, AJAX World RIA Conference, ERP Journal on Ulitzer

RIA & Ajax: Article

Real-World AJAX Book Preview: Base Services

Real-World AJAX Book Preview: Base Services

This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs for the special pre-order price, click here for more information. Aimed at everyone from enterprise developers to self-taught scripters, Real-World AJAX: Secrets of the Masters is the perfect book for anyone who wants to start developing AJAX applications.

Base Services
At the lowest level you have base services, including legacy services, new services, and data services.

Legacy services, such as existing mainframe or ERP systems, can expose services typically through proprietary interfaces such as LU6.2 ACCP, or SAP's BAPI. These services usually provide both behavior and information bound to that behavior. In other words, there is functionality and structure.

New services are those services created from the ground up as services. These services have behavior as well as information bound to the behavior, but are built from scratch as services, so there's not much further abstraction required (see next level up). They are typically Web Services but don't have to be as a rule.

Data services, as the name implies, are databases, data files, or other data stores that can produce and consume data. They support some behavior, but just enough to manage the data interaction services.

Abstract Services
Abstract Services are services that exist on top of base services, in essence, putting easier-to-use and better organized layers on legacy, new, and data services. It's the role of the abstract layer to create order out of the base services that are typically raw services from existing systems and data sources. This layer of abstraction provides the following features and benefits:

  1. A mechanism to normalize both services and data so they are managed better by the upper layers
  2. A way to filter out services that are irrelevant to the SOA
  3. An easier approach to management and governance
Orchestration
For our purposes we can define orchestration as a standards-based mechanism that defines how Web Services work together. In this case, we're talking about the abstract service at the lower layer, including business logic, sequencing, exception handling, and process decomposition, such as service and process reuse.

Orchestrations can span a few internal systems, systems between organizations, or both. Moreover, orchestrations are long-running, multi-step transactions, almost always controlled by one business party, and are loosely coupled and asynchronous in nature.

We can consider orchestration as really another complete layer over abstract services per our architecture. Orchestration encapsulates these integration points, binding them together to form higher-level processes and composite services. Orchestrations should actually become services.

Orchestration is a necessity if you're building an SOA, intra- or inter-organization. It's the layer that creates business solutions from the vast array of abstract services and from information flows found in new and existing systems. Orchestration is a god-like control mechanism that can put our SOA to work, as well as provide a point of control. Orchestration layers let you change the way your business functions to define or redefine any business process on-the-fly as needed. This provides the business with the flexibility and agility needed to compete.

Orchestration must provide dynamic, flexible, and adaptable mechanisms to meet the changing needs of the domain. This is done by separating the process logic and the abstract services used. The loosely coupled nature of orchestration is key since all services don't have to be up and running at the same time for orchestrations to run. This is also essential for long-running transactions. And, as services change over time, there's usually no need to alter the orchestration layer to accommodate the changes. At least, not if they're architected properly.

Orchestration has the following properties:

  • A single instance of orchestration typically spans many instances of services and even organizations.
  • Most orchestrations leverage public standards such as BPEL.
  • Orchestrations can be public - available to everyone - or private - available just to the owner - or shared - for supply chain integration scenarios.
  • Orchestrations are usually driven from a single party; they're not always collaborative.
  • Orchestrations themselves can become services that are available to other services or orchestrations.
  • Orchestration is independent of the source and target systems. Changes can be made to orchestration without having to force changes to the source or target systems. In other words, this architecture is loosely coupled.
  • Orchestrations are always decomposable down to the base processes in the source or target systems.
Interface
The interface layer is where AJAX lives. The purpose of the interface layer is to make services - core, abstract, or those exposed through orchestration (see Figure 11.2) - available to human beings. In this architecture, AJAX communicates directly with these services through its asynchronous mechanisms and exposes the information or behavior to the user.

In the interface layers, SOA developers can mix and match services and information and bind them to a dynamic interface in a way that makes sense for the end user. For instance, you can take an abstracted data service to populate a customer list and a risk service to process against that list and another abstract data service to put the information back in the data store (see Figure 11.3).

By the way, this mechanism is the same with other interface development technologies, including Java, C++, and Ruby on Rails. However, AJAX's use of a more asynchronous interface makes it better suited to this type of application with an SOA and, as such, applies anytime you're interacting with abstract, orchestrated, or core services.

It's also helpful to note that the interface layer can interact with any service at any layer, including the core, abstract, and orchestrated services, and should be able to interact with services that are either course- or fine-grained.

Understanding SOA Levels
All SOAs aren't the same. As we deploy SOAs, I see patterns beginning to emerge that range from very primitive to very sophisticated, from low value to high value. The question is: What level is your SOA?

Level zero SOAs are those that simply send SOAP messages from system to system. There's little notion of true services. Instead they leverage Web Services as an information integration mechanism. Hardly a SOA but certainly a first step.

It's also important to note that you don't need Web Services to create an SOA. This is true for all levels.

Level 1 SOAs are those that also leverage everything in Level 0, but add the notion of a messaging/queuing system. Most Enterprise Service Buses (ESBs) are Level 1 SOAs, leveraging a messaging environment that uses service interfaces, but don't really deal with true services (behavior), and instead move information between entities like messages through queues.

While services are a part of Level 1 SOAs, they're really all about information and not about application behavior. For instance, while you invoke a service to push a message into a queue and retrieve a message off a queue, it's really leveraging services as a well-defined interface and not accessing application functionality. Sometimes SOA architects attempt to abstract application behavior using an ESB. If that's the case, you're moving up to a Level 4 SOA. However, doing this is typically more trouble than it's worth because you're dealing with information-oriented integration technology that's attempting to deal with services/behavior - an unnatural act.

Level 2 SOAs are those that leverage everything in Level 1 and add an element of transformation and routing. That means that the SOA can not only move information from source and target systems, leveraging service interfaces, but can transform the data/schemas to account for the differences in application semantics. And by adding the element of intelligent routing, you can route the information based on elements such as source, content, and logical operators in the SOA.

Level 3 SOAs are those that leverage everything in Level 2, adding a common directory service. The directory provides a point of discovery of processes, services, schemas, and such, letting all those leveraging the SOA easily locate and leverage assets. Without directories, the notion of service reuse - the real point of building an SOA - won't work. Directories are typically standards-based, including UDDI, LDAP, and sometimes more proprietary directories such as Active Directory.

Level 4 SOAs are those that leverage everything in Level 3, adding the notion of brokering and managing true services. Here's where brokering of application behavior comes into play. In other words, at this level, we're not only talking about managing information movement, but discovering and leveraging true services.

At this level we can broker services between systems, letting the systems both discover and leverage application behavior as though the functionality was local. This is the real goal of Web Services - the ability to share services and not worry about platform-specific issues or where the services are actually running.

What's important here is that we understand that the value is in the behavior, as well as the information bound to that behavior. This level of an SOA can provide for discovery, access, and management. Most SOAs are built with Level 4 capabilities in mind, but may work up to them from the lower levels. If you do that, make sure you're leveraging the right technology and standards that support all levels.

Finally, Level 5 SOAs are those that leverage everything in Level 4, adding the notion of orchestration. Orchestration is key, providing the architect with the ability to leverage exposed services and information flows, creating, in essence, a “meta-application” above the existing processes and services to solve business problems.

Actually, orchestration is another complete layer up the stack, over and above more traditional application integration approaches we deal with at the lower levels. Thus, orchestration is the science and mechanism of managing the movement of information and the invocation of services in the correct and proper order to support the management and execution of common processes that exist in and between organizations and internal applications. Orchestration provides another layer of easily defined and centrally managed processes that exist on top of existing processes, application services, and the data in any set of applications.

The goal of this kind of SOA is to define a mechanism to bind relevant processes that exist between internal and external systems to support the flow of information and logic between them, maximizing their mutual value. Moreover, we're looking to define a common, agreed-on process that exists between many organizations and has visibility into any number of integrated systems, as well as being visible to any system that needs to leverage the common process model.

As services - and the architectures that support them - become more of an asset to the enterprise, we need to begin to learn how to categorize the architectural patterns. Hence, the SOA levels discussion. This provides both a better understanding of what a true SOA is and lets us pick the right level to meet our business needs.

Enterprise AJAX Tools
While AJAX is a relatively new notion to the Web, and the enterprise, there are a few enterprise tools that are beginning to appear. The most promising are Microsoft's Atlas and Tibco's General Interface. Let's take a quick look at each one.

Microsoft Atlas is a new Web development technology that integrates client script libraries with the ASP.NET 2.0 server-based development framework. Atlas offers the same kind of development platform for client-based Web pages that ASP.NET offers for server-based pages (see Figure 11.4).

Atlas makes it possible to take advantage of AJAX techniques on the Web and enables you to create ASP.NET pages with a rich client and server communication. Atlas isn't just for ASP.NET. You can take advantage of the rich client framework to build client-centric Web apps that integrate with any back-end data provider, including data services.

TIBCO General Interface provides developers with drag-and-drop visual authoring tools for standard XML and XSD, SOAP, and WSDL communications, as well as HTTP/S GET and POST operations. General Interface users have access to TIBCO's General Interface Developer Community, an online resource. Also, by using its add-in architecture, TIBCO General Interface lets additional third-party packages plug into TIBCO General Interface (see Figure 11.5).

General Interface works with existing browser capabilities, letting users get a full-featured application instantly from a URL. The product claims to reduce development time and cost by using familiar APIs, visual authoring tools, step-through debugging, and extensible, reusable components. The visual tools are a Web-based application powered by General Interface using AJAX in Internet Explorer.

Summary
AJAX is a mere instance of a rich client interface for both SOA and the enterprise. It's the momentum behind AJAX that will ensure its place in most enterprises looking to employ rich clients, which are most enterprise-class businesses. However, this technology isn't always a slam-dunk.

You must first address your requirements before leveraging AJAX or, for that matter, any other technology.

At the end of the day, AJAX is just another part of the SOA solution and it needs to exist with other robust technologies that solve the problems at hand. Therefore, you must consider using AJAX holistically and in the context of other enabling technologies, standards, and the ultimate architecture.

Unlike traditional application development, where the database and application are designed, SOAs are as unique as snowflakes. When all is said and done, no two will be alike. However, as time goes on, common patterns emerge that let us share best practices when creating an SOA. We still need to travel further down the road before we can see the whole picture.

This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs, click here to order.

More Stories By David Linthicum

Dave Linthicum is Sr. VP at Cloud Technology Partners, and an internationally known cloud computing and SOA expert. He is a sought-after consultant, speaker, and blogger. In his career, Dave has formed or enhanced many of the ideas behind modern distributed computing including EAI, B2B Application Integration, and SOA, approaches and technologies in wide use today. In addition, he is the Editor-in-Chief of SYS-CON's Virtualization Journal.

For the last 10 years, he has focused on the technology and strategies around cloud computing, including working with several cloud computing startups. His industry experience includes tenure as CTO and CEO of several successful software and cloud computing companies, and upper-level management positions in Fortune 500 companies. In addition, he was an associate professor of computer science for eight years, and continues to lecture at major technical colleges and universities, including University of Virginia and Arizona State University. He keynotes at many leading technology conferences, and has several well-read columns and blogs. Linthicum has authored 10 books, including the ground-breaking "Enterprise Application Integration" and "B2B Application Integration." You can reach him at david@bluemountainlabs.com. Or follow him on Twitter. Or view his profile on LinkedIn.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.