Welcome!

Machine Learning Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Corey Roth

Related Topics: Machine Learning , Real-World AJAX Book

Machine Learning : Article

Real-World AJAX

There's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise

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 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 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 begin to deploy SOAs, I see patterns beginning to emerge that range from very primitive to very sophisticated, from low value to high value. So, 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 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 a 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.


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 [email protected] Or follow him on Twitter. Or view his profile on LinkedIn.

Comments (22) View Comments

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.


Most Recent Comments
AJAXWorld News Desk 10/22/06 09:40:08 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

SYS-CON Italy News Desk 10/22/06 09:23:07 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

AJAXWorld News Desk 10/22/06 05:49:03 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

j j 09/28/06 08:45:16 AM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

j j 09/27/06 07:42:46 PM EDT

Thank you for your comment, please review it here before making your final post. Please note that we do not accept HTML in any of the fields; your carriage returns will be automatically perserved for you. Any URL's you include, starting with 'http' will be auto hyperlinked. You must supply at least a name and a comment. If you wish to keep track of this feedback then please supply your email address.

j j 09/27/06 06:43:50 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

j j 09/20/06 08:53:17 AM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

j j 09/19/06 06:14:25 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

j j 09/19/06 03:45:44 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

j j 09/19/06 03:31:17 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

j j 09/19/06 03:22:39 PM EDT

David Linthicum On the Enterprise Potential of AJAX

j j 09/19/06 02:52:35 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

n d 09/18/06 04:32:00 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

n d 09/18/06 03:38:01 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.
n d

n d 09/18/06 02:18:17 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

AJAXWorld News Desk 08/15/06 08:31:45 AM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

Upcoming Rails 1.2 08/12/06 03:55:11 AM EDT

The simply_restful plugin has now been added to the core, taking advantage of some of the HTTP verbs. This is big news, especially for web services.

It seems that by Rails 1.3 all Ajax macros will be taken out of the core and moved to plugins. This makes a lot of sense because Ajax isn't a core functionality, it is a user interface enhancement.

web2worker 08/12/06 03:52:51 AM EDT

> AJAX is a mere instance of a rich client
> interface for both SOA and the enterprise. > It's the momentum behind AJAX that will
> insure 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.

That is very succinct. Mr Linthicum is spot-on with this observation.

AJAXWorld News Desk 08/11/06 08:19:19 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

JDJ News Desk 08/11/06 06:56:33 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

AJAXWorld News Desk 08/11/06 06:15:45 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

AJAXWorld News Desk 08/11/06 05:50:55 PM EDT

As we move to next-generation enterprise architectures using newer notions such as Service Oriented Architecture (SOA), there's a need for a dynamic Web interface that can layer over services and provide more value to the enterprise. Moreover, the enterprise in general can benefit from the advantages of AJAX; it's just a matter of making enterprise developers as well as the SOA architects aware of AJAX.

CloudEXPO Stories
When applications are hosted on servers, they produce immense quantities of logging data. Quality engineers should verify that apps are producing log data that is existent, correct, consumable, and complete. Otherwise, apps in production are not easily monitored, have issues that are difficult to detect, and cannot be corrected quickly. Tom Chavez presents the four steps that quality engineers should include in every test plan for apps that produce log output or other machine data. Learn the steps so your team's apps not only function but also can be monitored and understood from their machine data when running in production.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
A valuable conference experience generates new contacts, sales leads, potential strategic partners and potential investors; helps gather competitive intelligence and even provides inspiration for new products and services. Conference Guru works with conference organizers to pass great deals to great conferences, helping you discover new conferences and increase your return on investment.
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure using the Kublr platform, and how Kubernetes objects, such as persistent volumes, ingress rules, and services, can be used to abstract from the infrastructure.