Making Service Oriented Architecture (SOA) A Reality In Today's Enterprise

Glenn Coward

Product Manager

Novell, Inc.

Apache Axis Example

Agenda

Introduction and Example Overview

1

What is SOA?

What will become of SOA?

SOA and WSF standards

MS Net Example

Service Orchestration Examples

Registry Example

Rich Macromedia Flex SOA Client Example

2

3

7

4

5

6

9

8

Workshop Themes

Strategic use of OSS and commercial software in building rich SOA today

The importance of process in SOA

Focus on code examples and SOA concepts by looking at working examples of SOA

Use of RAD SOA technologies in delivering favorable ROI's

What is SOA?

Benefits of SOA

Consistency of process

Reduction in duplicate work

Ease of maintenance

Broad interoperability

Logic reusability

Logic sharing

Inventory_Status_.IDBC

Gather_Info_From_eDir

Create_Calculator_Request

Java_Pricing_Web_Services

Purchase_Authority_Check

Generate_Shipping_Document

MB_Shipping_Web_Service

Send_Status_Notifications

Gather_Product_Information.IDBC

Methodology or style of development that maximizes service reusability, interoperability and sharing in distributed systems.

What is SOA? - Burton

NAP = the foundation that SOA are built on

Services bus

Infrastructure services model (ISM)

Service Design Practices (SPD)

The NAP defines the API's frameworks and protocols. The NAP lays the foundation for interop.

SOA

What is SOA? - Services Bus

Messaging middleware

Services discovery, binding and invocation

Standards based API's

Asynchronous

Routing

Guaranteed Delivery

Transformation

Security

What is SOA? - ISM

Basically WSM + WSR + AS container services

Web Services Foundation Middleware (WSFM)

Registry for cataloging services

Ability to inquire about services

Information needed for binding to services

Securing services

Lifecycle management of services

Monitoring and auditing of services

Transaction container services

Clustering and routing of service requests

Load balancing

Policy creation and runtime enforcement

Intermediary services like filtering, header infusion and transformation

What is SOA? - Simplified View

Composite Application Framework (CAF)

Composite Application Management CAM

User facing flow

User/Systems interface

Middleware Services

Business Process Management (BPM)

Enterprise Services Bus (ESB)

Integration (EAI)

Identity Services Foundation

WSM/SOM/IDM

Directory

Registry

What is WSF?

Web Services Framework is the body of web services standards

WSF is preferred way to deliver on SOA

WSF Taxonomy

Foundation Services

Extensions

Security

Orchestration

Reliability

Transactions

Management

Runtime management and provisioning

SOA Trends – Based on IDC Research

Market stays favorable to SOA

Tough times drive to standards based SOA over proprietary options

Large orgs will build enterprise class SOA first to be followed by SMB

Many initial WSF projects are achieving great ROI's

Companies are creating WSF/shared services tiger teams

Focus is changing to managing and securing web services

Focus is shifting to client or WS consumers

SOA Trends - Acquisitions

HP acquired Talking Blocks

WebMethods acquired Mind Electric

Oblix acquired Confluent

All are/were SOM vendors

SOA Trends

Why are companies investing in SOA

Asset Protection

Extending legacy systems

Interoperability

Promote reuse of new investments

Bridge MS and J2EE

Fix hastily built web apps

Extend information to constituents

WSF Standards Evolution

States of ratification

Two standards camps

IBM, BEA, MS, HP

Sun, Oracle

Accepted

Evolving

Proposed

Conflicting

Accepted Standards

HTTP 1.1

XML 1.0

SOAP 1.1

XML Schema 1.0

WSDL 1.1

UDDI 2.0

Xpath 1.0

XSLT 1.0

WS-Security

X.509

WSRP

Tobe WSF Standards in 2005

XML 1.1

SOAP 1.2

XOP/MTOM

WSDL 2.0

UDDI 3.0

Xpath 2.0, Xquery

WS-Security

SAML

Standards Activity

Communication

Messaging

Addressing

Description

Discovery

Data Management

Security

Reliability

Transactions

Orchestration

Presentation

Management

Provisioning

Axis Demonstration

Novell Linux Desktop (NLD)

Eclipse 3.0.1

Axis 1.1

Xdoclet 1.2.2

Jboss 4.0.1

MySQl 4.1.0

Axis Script - Service

RaceDayAxis

public String getTimeAsString(String arg) throws RemoteException;

RaceDayAxisBean

public String getTimeAsString(String arg) throws RemoteException {

System.out.println("RaceDayAxisBean called. Delegating to RaceDayAxisImpl");

return timeService.getTimeAsString(arg);

}

Axis Script - Implementation

RaceDayAxisImpl

/**

* Return the current time and date as a string.

*

* @web.interface-method

* @return the current time and date as a string.

*/

public String getTimeAsString(String arg) {

String time = new Date().toString();

System.out.println("getTimeAsString called. Returning: " + time + "input = " + arg);

time = time + " input arg value = " + arg;

return time;

}

Axis Script – Junit Test

WebServiceTests

public void testGetTimeAsString() {

String response = null;

if(client == null) client = new RaceDayAxisDIIClient(args);

try {

response = client.invokeMethod("getTimeAsString","String_1", "string","time test");

}

catch(Exception e) {

e.printStackTrace();

}

assertNotNull("testGetTimeAsString()executed", response);

}

MS NET Demonstration

Visual Studio 7.0

MS.Net Framework 1.0.3

ISS 5.0

MS C#

SQL Server 7

Services Orchestration Demonstration

Chaining of granular service endpoints

Process is exposed to consumers

Often called asynchronously

Process is an important SOA layer

RaceDayCreateJBoss

RaceDayReadJBoss

RaceDayUpdateJBoss

RaceDayDeleteJBoss

ConfirmationEmail

RaceDayCreateMNNet

Registry Discussion and Demonstration

Embedded rich client registration interface

Portal provides security and personalization

SOAP communication between SOA processes and consuming clients

Rich Flash SOA Client Demonstration

Macromedia Flex 1.5

Uses Flash Technology

Macromedia Flex Builder 1.5

Can use any client technology that can be embedded in a portal and speaks SOAP

Conclusion

Use a combination of OSS and commercial software in building rich SOA today

Process is a critical component of SOA

Expose course business level services interfaces and access through portal managed, even rich clients

Use RAD technologies for the top level services consider OSS for the static back end services

The basic workshop flow is from SOA theory and market analysis to understanding by examining an actual SOA style application that includes the following components:

- Multiple servers (User interface, Process and Integration, Service implementation in .Net and Service implementation on Linux.

- Multiple application servers (.Net and Jboss4)

- Opens source and proprietary web service engines (Axis 1.1 and MS.Net)

- Business Process Management (WSFL as example of BPEL)

- Portal type user interface with embedded rich client (Macromedia Flex)

- Registration and management of services via UDDI registry (Systinet Business Registry)

- Integration with SMTP based asynchronous messaging service

All communication between the client, process manager and services endpoints is via standards compliant SOAP

We will inspect the SOAP messages that are passed between SOA components and examine implementation code.

For most organizations, the best way to approach the technology aspect of implementing SOA is use a strategic combination of open source and commercial offerings.

Consider OSS:

- Platform (Linux)

- Low level engines like AS that manage secure, stable, static logic

Consider Commercial for:

- Security and Identity infrastructure

- Business process and deep integration

- Dynamic, changing user interface and rich clients

At the heart of SOA is the concept of services orchestration (BPEL)

One of the best ways to conceptualize the full SOA implementation stack is to see one running and examine it's parts.

With todays technology, you should expect RAD and Rich capabilities in your SOA implementation, not just low level coding with thin clients.

SOA provides for the encoding of complex business process that may exist only in the heads of employees, customers or partners.

Most large organizations have a small set of 10-12 core business processes that drive revenue. Identify these and start with the one of lowest risk.

SOA allows for a balanced and systemic process that includes both user and system within the same managed process.

Components of the SOA are modular and present a well defined, durable contract that prevents changes in one component from breaking another.

Components can be reused in many orchestrations. For example a login component can be used in many SOA orchestrations just like an abstract use case is used in modeling redundant requirements.

Components and combinations of components can be exposed through a public SOAP interface and registered so that authorized remote consumers can bind and execute service components.

The primary technology for implementing SOA is WSF (Web Services Foundation), therefor, all the advantages of WSF are included in SOA.

Burton defines SOA as a style of development for creating shared, reusable, distributed services and accessing them in a composite app manner.

The NAP (Network Application Platform) is basically the foundation that SOA style apps are built on. It consists of:

- A services bus that could be considered the WSF (Web Services Foundation) + Process + Integration. This could be the ESB(Enterprise Services Bus) in the future.

- ISM(Infrastructure Services Model). This is basically the core runtime services container, for example the AS(Application Server)

- SDP(Services Design Practices). This is basically a SOA centric methodology that includes provision for remote services, distributed development and management and business process management.

Perhaps it should also include provisioning of the development and management interface that accompanies course public services.

Messaging middleware allows for the invocation of asynchronous services. For example, a registration process may not force the registration client interface to block while all back end services are executed.

General best practice is to implement SOA service end points in an async manner unless the result of the service execution is required immediately by the client.

The challenge is how to do async as there is currently no standard binding for SOAP over SMTP/JMS

The services bus should include a UDDIv3 registry service as UDDIv3 is the meta store for all the information about a web service. It also serves as the persistence store WSM(Web Services Management) capabilities.

One way to conceptualize the Services Bus is to think of it as the evolution of the MOM(Messaging Oriented Middleware). It adds a SOAP interface to the the MOM's standard JMS interface. It adds managed routing via BPM(BPEL) and provides guaranteed delivery and transactional services that have existed in the MOM realm for some time.

Basically, the services bus is the combination of a traditional MOM and functionality that implements the WSF(Web Service Framework).

The WSF is simply the sum of all accepted web services standards.

The ISM is basically the runtime engines or containers that manage the services themselves as opposed to messaging or routing of service interactions or orchestration.

In our example, the ISM consists of the Systinet Registry, Jboss4 Application Server, Novell exteNd Application Server and MS.Net Server.

The ISM is all the things that surround the service and give it life. Furthermore the ISM is used to manage the service's lifecycle.

Note that many of the items listed are what we would consider traditional application server container services.

So, the boiled down definition of SOA could be better understood by looking at the anatomy of a complete SOA style application.

An SOA style application is more or less the combination of things we already know:

- Composite Applications user interface that presents an aggregate view of information from many data sources in a portal type interface

- Middleware services that allow us to abstract granular legacy information into course business level interfaces. Where possible this is done in an asynchronous manner.

- Services runtime and management engines that bring life to our services, provide security, auditing, request routing, transactions, lifecycle support, etc.

So, one could consider an SOA style application, the full set of functionality from a rich client running in a portal to a low level Axis based web service running in the Jboss container on Linux.

The important thing is that the contract between all components of the app be WSF compliant (SOAP) and how they communicate via standards.

Burton defines WSF as an increasingly comprehensive collection of platform-independent standards that supports services-oriented integration and heterogeneous interoperability.

In the past, SOA may have been implemented via proprietary EAI products. This has been one of the major obstacles to broad SOA adoption. This is why the WSF exists.

The WSF provides a standard layer through which and consumer can interact with any producer.

The foundation services are those that support basic, simple service interoperability. This could be considered those standards that enable RPC style service interop.

Extensions are where most of the standards activity currently is happening. There are evolving, proposed and conflicting standards submissions. Users beware until ratified and/or profiled.

According to IDC:

The market will continue to adopt WSF style SOA over the next 4 years, culminating with web services being used by virtually all domestic organizations of any size by 2008.

The first to enter the game will be large organizations that must make a systemic effort to get into SOA. They can't ease into it. Many of these organizations have had isolated successes with web services and are starting to understand SOA style methodology and technology. They have experienced favorable ROI's on these isolated projects and as a result have gained business sponsors.

The high cost of proprietary EAI products will continue to drive SOA customers towards open source and the use of standard interop protocols like SOAP and the WSF.

It's becoming difficult for organizations to keep up with web service end points, security, versioning, auditing and service levels and the value of the ISM, specifically WSR(Web Services Registry) and WSM (Web Services Management) is becoming more evident.

Evidence of consolidation in the WSF market.

All of these acquisitions were intended to position the acquirer to play in the services management space.

The idea being that the next wave of SOA adoption will require the management of services instead of just the ability to create, produce and consume them.

Organizations no longer have the luxury of scrapping old systems and replacing them with new ones. Economic hardships have resulted in a need to protect current IT investments and extend and/or improve legacy systems.

Organizations want to make siloed legacy data accessible and enable transactions against legacy systems by a variety of clients. The catch is that back end interactions must be standards based orchestrations of granular legacy interfaces, performant, secure and manageable.

New systems or extensions to existing assets must naturally participate in an open interoperability model.

The primary use case for web services at this time is the integration of MS and J2EE logic. SOA architecture should include provision for this and SOA tools must enable it.

There are many prospective WSF standards. They tend to fall into categories of adoption as generally defined by Burton.

- Accepted standards are ratified and/or profiled and in wide spread use.

Customers should not be concerned about interoperability if implementation is kept to accepted standards

Current accepted standards (HTTP 1.1, XML 1.0, SOAP 1.1, XML Schema 1.0, WSDL 1.1 UDDI 3.0, Xpath 1.0, XSLT 1.0, WS-Security, Username and X.509 tokens, WSRP)

- Evolving standards are the evolution of current accepted standards. Examples include: (SOAP 1.2, Xpath 2.0, XML 1.1, WSDL 2.0)

- Proposed standards are new and have industry backing but are still being developed or are usually owned and managed by group of commercial vendors. Examples include: (SAML, MIME, WS-Discovery, WS-BPEL)

- Conflicting standards are intended to solve the same fundamental use case and are competing for mind share. For example: (WS_Notification by MS and WS-Notification by IBM, WS-Reliability by Sun and WS-ReliableMessaging by MS)

Note that accepted standards are those that are in widespread use but not profiled or ratified as in XMLSchema 1.0 and Xpath 1.0.

Accepted standards may also be profiled but not ratified as in SAOP 1.1 or ratified but not yet profiled as in XML 1.0.

In a perfect world, standards would be both ratified by a standards body like the W3C or OASIS and profiled by WS-I before being classified as accepted.

Expect your WSF vendors to support standards that have been ratified, profiled or are in widespread use. Inquire about evolving and proposed standards that are likely to be ratified, profiled or in wide spread use within the next year.

XOP/MTOM , RRSHB, and UDDIv3 were all ratified in early 2005 The W3C ratified all but UDDv3. UDDIv3 was ratified by OASIS. All this took place in the last week of January 05.

XML 1.1 is a new encoding style for XML content. It has been ratified by the W3C but is not officially part of the WSF yet. Expected in 06

SOAP 1.2 has also been ratified but is not yet an official part of the WSF because it's not widely supported. It removes ambiguity and formalizes the extensibility model through features and modules.

XOP/MTOM is a SOAP 1.2 abstract feature that defines the mechanism for encoding binary content using base64binary.

UDDIv3 makes the registry an essential component of the WSF as the primary meta store for everything about a web service including, policy, security, versioning, SLA. It also defines a new extensible information model for schema extensions

SAML2.0 provides for the federation of web services and implements the Liberty Specification.

A common implementation pattern will be to create low level business logic on OSS platforms like Linux with OSS frameworks and tooling like Axis and Eclipse, running on OSS AS containers like Jboss.

These services will then be exposed to business process activities that will then expose a course business level interface to consumers.

The workshop example uses a set of CRUD(Create, Read, Update, Delete) services implemented in this configuration.

The business scenario is a race registration and the CRUD services themselves are not exposed in a public contract to the consuming portal application . Nevertheless, they are used by the business process to persist registration information to both Linux and MS.Net legacy systems.

J2EE 1.4 supports a new capability of deploying SLSB's (Stateless Session Level Bean) or Servlets as web services simply by adding descriptors indicating this intent. Actually, there is a little more to it, but not much.

This example defines an interface for the web services and an implementation of the bean class that completes all the source necessary to expose an SLSB as a web service. Note that Xdoclet was used to generate the remaining EJB classes needed for the SLSB.

In the example, the bean and the servlet both call an implementation class that performs the actual logic.

In this Eclipse, Axis, Jboss open source centric scenario, Junit will most likely be used for unit testing, therefor, the example uses Junit to test the new web services.

In the example, Junit is invoked from the Ant build script.

According to IDC, the primary usage scenario for web services currently is to integrate J2EE and MS.NET logic.

For this reason, the example implements a subset of the CRUD services in both MS.NET and J2EE/JBoss.

Although Java and C# are quite similar in syntax and the J2EE and MS.NET platforms serve a similar purpose, the code that implements the web services is quite different.

One fundamental runtime difference is that MS.NET defaults web service encoding to Document Literal SOAP whereas J2EE 1.4 defaults to RPC Literal SOAP.

The example will demonstrate this and examine the differences.

ExteNd Composer is used to implement the critical process layer of the SOA application. Best SOA practice is expose a public service interface at the business level, not the technology level. Therefore, a business process like “register” is exposed to clients rather than a technology service like create, delete, read or update.

The BPM framework and related services should provide additional value to the service such as security, load balancing, transaction, expose multiple interfaces, messaging, auditing and durability. The process is often called in an asynchronous manner, whereas the granular technology services are call synchronously.

2003-12-08T12:43:39