NextAxiom Hyperservice® Studio
Hyperservice® Studio
Features
Integrated Services Environment for Pure Service-Oriented
Development of Business Services
Web services are network-enabled software functions that conform
to industry standards for their interface and consumption. These
standards allow software functions to be thought of as standardized
building blocks, enabling an entirely new paradigm of business
component development that breaks new ground in business
agility. The Hyperservice Studio is an innovative Integrated Service
Environment (ISE) that supports many breakthrough features for
the pure service-oriented development of real-time business
services. The NextAxiom Studio is the core enabling component for
the Service-Oriented Development of Applications (SODA).
The
Hyperservice Studio enables you to produce business services
through metadata-driven composition and consumption of other
Web or native services. Your favorite UI development tool, Portal
development platform or end-user devices can then consume these
agile Business Services to support your ever-changing business
requirements.
Secure, Project-Based Collaboration
 Username/Password Authentication
 Role-based Access Control
 Supports offline and online
 Project and package organization
 Package links across projects
Secure Collaborative Environment for Online and Offline Use
The Hyperservice® Studio is designed for collaborative development of
business services. It provides role-based access control for the resources
within its development projects and enforces user authentication during the
login process. The user can choose to work offline upon login. In this case,
the Studio loads an OEM version of the NextAxiom Service Runtime
Environment (SRE) in its own program address space.
When working
offline, the internal SRE provides replicated metadata to the Studio. The
user can also choose to work in a connected mode by selecting a remote
NextAxiom SRE site. In this case, Studio switches from its internal SRE
and points to a remote SRE. NextAxiom SRE sites are identified by a URL
and easily managed within the Studio. Since every action that a user can
initiate through the Studio consumes one of the System Services, switching
from one SRE site (local or remote) to another is a matter of setting a URL
parameter on the Studio’s service consumption mechanism.
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
Hyperservice® Studio
Features
Project-based Service Development
Standards Compliance
 Web services (WSDL DOC/RPC) search
and import

UDDI registries

Local WSDL files

Remote WSDL URL

Web services on NextAxiom
Projects

Granular search for keywords
and interfaces (input/output
fields and descriptions)
Each project is represented by a tree structure and can be sub organized
 Web services export

Both DOC and RPC style WSDL
generation

Publish to UDDI registries
The Hyperservice Studio uses projects for organizing development efforts.
into packages that are analogous to folders in a file system. Each package
can contain any number of sub packages.
Imported and new service
interfaces and composite definition metadata are organized under
packages. These resources can be linked and reused from one Studio
project to another without the need for duplication. The Studio provides a
powerful metadata search and discovery facility within and across projects.
A service interface corresponds to a single WSDL operation and a package
of service interfaces corresponds to multiple operations within a WSDL
specification. At anytime, the user can generate WSDL from a service
interface or package of service interfaces in the project pane or import
 Service interface input/output
definition

From DTD

From XML Schema (XSD)
Pre-built Service Interfaces
 Communications/Invocation
 SOAP, FTP, SMTP, POP3, JMS,
HTTP
 XML communication
 Command line
 Data access
 Text and Excel files
 Databases
 Message Queues
external WSDL into the project pane under a package.
Leverage Web services from Any Source
The Hyperservice® Studio allows you to search and import service
interfaces as WSDL through any UDDI compliant registry. It also enables
you to import WSDL directly from a file or a URL. NextAxiom supports both
Document and RPC styles of WSDL and works with all commercially
available Web services coding platforms. The Studio leverages Web
services from any source: services provided by internal applications such
as CRM or ERP systems, new services coded in-house in any
programming language and using any low-level development platform such
as Microsoft® .NET, BEA WebLogic or IBM WebSphere, services provided
by integration vendors, and services provided by outside business partners
or on-line businesses such Amazon.com and eBay.
Directly Leverage Your Legacy Assets as Services
The Hyperservice Studio provides many built-in standard services such as
services for FTP, email, platform independent file system operations, bulk
file read/write, HTTP operations, and JMS integration to name a few. We
refer to these services as Standard Services.
The standard service
interfaces are packaged in the Studio’s Standard project and can be easily
linked to any new project created within the Studio and consumed within
any business service. The Standard service interfaces are implemented
through a Service Plug-in Framework that is supported by the SRE at any
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
business service. The Standard service interfaces are implemented
through a Service Plug-in Framework that is supported by the SRE at
runtime. The Service Plug-in Framework can be used in a similar way to
turn the functionality of any legacy system (homegrown or customized
packaged application) to a set of native services with well-defined
interfaces. Native services are also provided through easy-to-use wizards.
The Hyperservice Studio is shipped with built-in wizards that provide
services for structured data exchange through existing messaging
infrastructures, XML processing and communication, formatted flat file or
XML file read/write, Excel read/write and query/write operations across any
ODBC/JDBC compliant database. Service wizards can be used in a similar
way to turn the functionality of your existing assets into services. Wizards
are plugged into the Studio through a Service Wizard Framework. This
framework extends the user interface of the Studio’s ISE to systematically
encompass a visual perspective into your existing software assets as
services. Once a wizard is plugged into the Studio, it systematically walks
the service developer through simple steps to create service interfaces that
wrap around your legacy application components. The runtime of these
interfaces can be supported automatically by the SRE through the Service
Plug-in Framework.
Develop, View and Configure Service Interfaces for SRE
Automation
We already touched on built-in standard services, service wizards and
importing Web services. With the Studio, you can also create new service
interfaces. The Hyperservice® Studio provides a sophisticated interface
editor for creating and viewing service interfaces. Using the interface editor,
simple or complex service input and output structures can be defined from
scratch or imported from DTD, XML Schema (XSD) or copied form another
service interface. The service input and output structures can be exported
as an XML Schema. The Studio provides a Reusable Data Container type
mechanism for reusing and sharing complex data types across two or more
services without duplication. These reusable types can be restricted to a
single project or made available to all projects within the Studio. Each input
or output data type carries its own restrictions, automatic XML translation
properties, documentation, and other advanced properties. For example,
an input type can be marked as a cache key. This instructs the SRE to use
the actual value of that input field as part of the cache key when caching
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
the outputs of the service. Using the XML translation properties, at
runtime, a service’s input and output data can be automatically translated
to XML or loaded from XML by the SRE.
There is also an important set of automation properties attached to a
service interface itself that serves as an automation contract between the
Studio and the SRE. These properties are organized into many categories.
One interesting category of automation properties is the “runtime” category
of properties. For example, a runtime property determines whether at
runtime a service instance relating to an interface should be logged and
whether to log actual input and/or output data of the service as well as the
information about the consumption of the service.
Another runtime property determines whether to run multiple concurrent
requests in serial or in parallel and how to limit and throttle the number of
concurrent threads when running an instance of the service in a batch-
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
processing mode. Another powerful runtime property is the “serialization”
property. If this property is enabled, concurrent requests for running
instances of the service interface are guaranteed to be serialized one at a
time regardless of input values, or only for requests that have the same
values for selected inputs.
This is analogous to row level locking in
relational database management systems. The property sheet for
serialization of consumption allows you to add the service interface to a
service group and thereby instruct the SRE to serialize consumption across
all the service instances belonging to any service interface in that group
keyed by specific service inputs.
As another interesting example of a runtime property, the “implementation”
property determines whether a service is atomic or composite. An Atomic
service points to a registered Service Plug-in.
A Composite service is
defined using other Studio metadata as a purely service-oriented and
visual program referred to as a Hyperservice®. Here, we covered only a few
properties of the service interface.
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
Hyperservice® Studio
Features
Visual Service Interface Editor
 Request/Response development
 Graphical display of inputs and
outputs
 Accepts fields of any data type or
structure
 Supports any level of hierarchical
data structures
 Specify optional and required fields
 Specify default values and value
restrictions
 Specify XML attribute
Visually Reuse and Define Real-time Business Services Onthe-fly
IT administrators can monitor total system load, change priority of a
service, pause/resume and abort running services. The Hyperservice®
Manager also provides a facility to monitor and manage the contents of the
SRE service cache. Adjusting the size of the in-memory cache and its disk
swap threshold can optimize the performance of the cache. The contents
of the cache entries can be examined and selectively purged through the
Manager.
 Import definitions from WSDL, XML
Schema (XSD), DTD, or XML instances
 Configurable types for late binding
 Identify input cache keys
 Configure runtime automation
properties
 Identify implementation
 Service parameters
 Parallel/serialized batch properties
 Logging properties
 Define message codes
 Serialization properties for concurrent
consumption
 All requests
 Only request with same
correlation key
 All requests across a service group
 All request across a service group
with same correlation key
Each service that is dragged and dropped inside a Hyperservice has an
activation port on the left side and a success and failure port on the right
side. When the success port of one service is connected to the activation
port of another, a dependant order of execution is established. By
connecting the failure port of a service to the activation port of another, a
service-oriented exception-handling route is established.
Services are
linked together to determine the order of execution. Complex outputs and
inputs across many-to-many connected services can be visually mapped
without ever leaving the Studio.
Built-in programming constructs for logical operations such as “And” “Or”,
and “Not”, conditional branching such as data-driven “if-else” logic,
batching (“for each”), and exit and continue constructs can be dragged
from a pallet and connected to Hyperservice inputs or outputs of the inner
services for controlling the flow of execution and expressing business and
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
management logic across inner-services. A slew of built-in configurable
services are available to sort, filter any service output data, generate
formatted text, crunch numbers and apply one of many transformation
functions to the outputs of inner services. A special set of configurable
services
are
provided
for
data
list
manipulation
and
structural
transformation of service data. A Hyperservice can be designed to loop
over its consumption infinitely or for an exactly pre-specified number of
iterations.
The loop properties can be configured to pause a specified
number of milliseconds between each iteration in order to create monitoring
Hyperservices.
A Hyperservice enables the context-sensitive behavior of its inner services.
For example, an inner service can be automatically cached at runtime and
purged after a specified time interval. Here, the first time an inner service is
consumed in this context its outputs are cached correlated to key inputs.
Subsequent calls in this context with the same key inputs, result in fetching
the outputs from cache instead of actually consuming the service.
The logging behavior of each inner service can be also overwritten in the
context of a particular Hyperservice. Furthermore, a Hyperservice can be
marked as a transaction boundary. In which case, the SRE creates a
transactional context and automatically invokes the compensators for each
of the inner services, if any, upon the rollback of that context. A
compensator is itself a Hyperservice that can be defined and attached to
any Hyperservice.
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
Hyperservice® Studio
The Studio provides a shared memory mechanism that can be used to
Features
share data across native service instances at runtime. The shared memory
Semantic-Based Inter service
Communications
 Shared Memory Services
 Shared Data Container
 Shared Vault
 Shared Array
 Shared Dictionary for translation
 Synchronized access to protect
integrity
 Wait/Notification and asynchronous
communication between services
 Defining Request Events
o
Wait
o
Correlation
o
Notification
 Defining Service Triggers
o
Installing Triggers
o
Attaching
Hyperservices
mechanism is an extensible framework that currently supports four types of
shared memory: Shared Container, Shared Vault, Shared Array, and
Shared Dictionary. Shared Dictionary is used for translation lookups. For
example, it can relate “BR”, “BRWN”, and “BRN” to “Brown” for eye color
across different law enforcement agencies. The Shared Vault is a lookup
table that can hold structured data coming from input/outputs of services in
a lookup table and provide notification to running services when a particular
key/data pair is inserted in a vault.
All shared memory work in a similar way. For example, to create a new
vault for Sales Orders, you first create a new vault named Sales Order,
with the Sales Order data structure, you then open the vault and drag and
drop its access services into any Hyperservice. For example, you can drop
the Set Data with Key vault service into a Hyperservice to put some Sales
Order data coming from another service into the vault.
Hyperservices can be embedded within other Hyperservices without no
limit of depth. The Hyperservice editor provides a mechanism to select a
subset of services and logic inside of a Hyperservice and automatically
factor them out as a separate Hyperservice.
This is one of the
mechanisms that encourages reusability of services.
The Studio also
provides ‘where used’ functionality as well as a Hyperservice explorer that
can display the hierarchical composition of a Hyperservice in a tree like
structure. The Hyperservice explorer is completely integrated and
coordinated with the project pane.
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
Hyperservice® Studio
Features
Visually Define Long Running Business Service On-the-fly
Business Service Programming
business services. The first mechanism enables the user to add a Request
 Define Hyperservice Programs
 Drop any service into a hyperservice
 Graphically define routing between
services
 Status-based (success or failure)
 Logical (AND, OR, NOT)
 Decision-based (IF-THEN-ELSE)
Event on any service interface within a project and identify correlation keys
 Use









request event with the specified correlation key. The second mechanism is
Configurable Constructs
Merge, split
Sort
Filter
Calculator
Text formatter
XML transformation
Data list manipulation
Data structure morphing
Built-in functions
The Studio exposes two mechanisms for accommodating long running
from within the inputs of that service. This Request Event provides a
specific Wait service that takes those correlation keys as inputs. The Wait
service can be dragged and dropped into any Hyperservice to block the
execution of the Hyperservice at runtime until it is notified through a
the Wait action of the Shared Vault mechanism. It is similar to the request
Event mechanism except it provides persistent storage and can be
integrated directly into external messaging systems.
 Configure Hyperservice properties
 Repeat looping, pause between
repeat
 Data feedback
 Log setting override
 Transaction boundary
 Define Data flow
 Field mapping between interfaces
 Many-to-many inputs/outputs
 Automatic data flattening
 Automatic type conversion
 Drop-in data processing functions
 Transformations
 Mathematical operations
 Define context-sensitive service
caching, logging
Design-time Debugging, Testing and
Profiling
Visually Define Management Services and Install Service
 Run services as black boxes
 Add simple or complex input data
 View simple and complex output
data
 Save multiple datasets sets for a
service
 Define sets of inputs and expected
outputs
 One-click regression testing at the
package or project level
 Test result reporting
You can use Hyperservices to define and encapsulate your IT and
 Run Business services as glass boxes
 Supports offline or remote
debugging
 Set multiple breakpoints
Triggers
application management logic the same way you encapsulate your
business application logic. Application management policies and IT
monitors can be defined and implemented through Hyperservices.
A
Hyperservice can be designed to loop in specific intervals and act similar to
a process daemon.
The Studio Service Trigger is an example of another
built-in mechanism that allows you to non-intrusively add management
logic next to your application logic. You can easily add a trigger to any
service interface within the Studio. Then, you can attach any number of
Hyperservice programs to that trigger. The trigger can be configured to
activate each of the Hyperservice programs upon the start, end, failure, or
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
Hyperservice® Studio
Features
success of the triggering service.
The trigger mechanism within the SRE makes the actual inputs and outputs
 Run step at a time or up to a
breakpoint
 View input and output data for each
inner service
 Step-into inner composite services
 Modify input and output values and
rerun
of the triggering service available to the Hyperservices attached to the
trigger. For example, if your business process steps are accessed through
services, by adding a trigger on each service and the Shared Vault
mechanism and correlation keys, you can seamlessly gather data for
measuring the process cycle time between each step. Ability to measure
 Examine runtime profile as you
develop
 Inner service runtime statistics
 Time spent in the SRE vs. outside
NextAxiom
Relative inner service execution charts
your process cycle time is an example of a management capability that can
help you improve your business. A Trigger that runs on the failure of a
service can be used to extend exception handling beyond what the
application developer originally implemented within the failed Business
Service without needing to modify the service.
Triggers can also be used to dynamically extend application functionality.
For example, users can subscribe to a particular item, within a specific
price range, that was not available at the time. The subscription service
can simply add the user’s email and the specification of the users request
to a shared memory structure. The business programmer can install a
trigger on the Add New Item service and attach a Hyperservice to that
trigger that is invoked upon the success of Add New Item. Each time a
new item arrives, the triggered Hyperservice can lookup the item in the
shared memory to find a match and synchronously peg the item to a user,
if any, and notify the user of its limited time availability through the Send
Email standard service.
Run Black Box and Regression Testing and View Test Profile
information as You Develop
The Hyperservice® Studio provides a test client that is used for black box
testing of an atomic or a composite service. The user adds input data to
each required input field of a service and views the output data that results
from the run of the service. The user can view the runtime profile of tested
services through the log analyzer. The log analyzer charts consumption
information of the inner services for each composite service that runs.
The test client also provides an option for the user to save one or more
input data sets and associate the corresponding outputs to those datasets
after running the service for each input data. Based on these saved input
and output datasets, the Studio provides a built-in regression facility that
can automatically run all test cases for every service under a specified
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved
packages or the entire project and produce a regression test report. The
report contains success/failure status of the service test and optionally
compares the outputs of the current regression test run with the outputs
from the previously saved results for each service.
Visually Debug Composite Services as Glass Boxes
The Studio provides a service inspector to visually run and debug a
composite service.
The user can set visual break points on any inner
service, run the inner services of a composite one at a time or up to a
break point and examine the inputs and outputs of each inner service that
ran.
The user can modify the input data of an inner service that had already run
and re-run it to simulate a what-if scenario. If an inner service is composite,
the user can step into the inner composite. In this case, the
Studio
creates and maintains a stack of inspectors and once an inner inspector
finishes it returns to the outer inspector and populates the outputs of the
inner most composite service.
Business Agility On Demand™
Copyright 2005 NextAxiom Technology Corporation. All Rights Reserved