BPEL in SCA assembly model

(For basics about SCA visit:

http://khanderaotech.blogspot.com/2007/02/basics-of-service-component.html)

SCA and BPEL are complementary technologies. Though both have a mechanism to capture relationship between services, both do it differently. Moreover, BPEL is an execution language while SCA captures only the dependencies.

BPEL process can be an implementation type of service(s) within SCA. One may define service using BPEL and deploy the composite.

BPEL capture relationship between a process and an interactive web service as a partnerlink with different roles tied to port types. SCA maps the partnerlink with a single role (port type) to a reference. Thus, mapping between SCA and BPEL is straightforward.

Let us assemble a composite containing a BPEL process. I am using a stripped down version of a PurchaseOrderProcess given in proposed WS-BPEL 2.0 specifications. This process invokes two other services one to compute price and another to ship the product. These relationships are captured in three partnerlinks.

In case of WS-BPEL, a partnerLink defines two roles, one for the WS-BPEL process and one for the partner. In SCA, Depending upon a message flow direction, one of them becomes a reference and another becomes a service.

In our example, the BPEL process’s interface is exposed as a service entry point of the composite while other partner links are mapped as references.

Invoice (computePrice) service and Shipping service can be local or external to the composite. I am making both of them as external webservices. Thus, our composite looks like:

You may notice, wires between component and references. The BPEL process does not know what kind of implementation those references and what kind of binding it has. This loose coupling and flexibility is a power of SCA architecture.

Finally, here is the SCA composite representation for this assembly.

Disclaimer: The specs are still being evolved and may change. The representation is simplified for explanation hence it is not complete.

References:

1. WS-BPEL 2.0 : http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.pdf

2. SCA whitepaper: http://www.osoa.org/display/Main/SCA+BPEL+White+Paper

3. SCA - BPEL specs: http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_v0.95.pdf?version=2

SCA

BPEL

JSR-311 Java API for REST approved ballot after a Mixed reactions from developers:

JSR proposal http://jcp.org/en/jsr/detail?id=311


JCP formed a JSR expert group to publish an API for RESTful services. JSR-311 is in ballot review period in this month (till Feb 26). Software companies like Apache, BEA, Google,JBoss and Sun Microsystems are on the board. Individuals like Jerom Louvel (RESTlet framework) and Douge Lea are also on board of it. However, according to others, Roy Fielding whose dissertations documented the REST pattern, seems to be unhappy about Sun using REST as a name.

According to this request, this JSR intends to provide a high level easy to use API for developers to write RESTful web services that would run on top of the Java EE or the Java SE platforms. The JSR would provide API with declarative style of programming using annotations for developers. It would also enable low level access in cases where needed by the application.

Sun's lead on this specification, Marc Hadley, outlined following conceptual model:

@UriTemplate("widgets/{widgetid}")
@ConsumeMime("application/widgets+xml")
@ProduceMime("application/widgets+xml")
public class Widget {

@HttpMethod(GET)
public Representation getWidget(@UriParam("widgetid") String id) {
String replyStr = getWidgetAsXml(id);
return new StringRepresentation(replyStr,
"application/widgets+xml");
}

@HttpMethod(PUT)
public void updateWidget(@UriParam("widgetid") String id,
Representation update) {
updateWidgetFromXml(id, update);
}

@LastModified
public Date getChangeDate(@UriParam("widgetid") String id) {
return getLastChanged(id);
}
}

Interestingly, the JSR furthers states " The specification will define
how RESTful services are deployed as JAX-WS (Java API for XML Web
Services) endpoints or Servlets."  The API will be packaged as javax.ws.rest.
I assume there could be WSDL representation of this using HTTP binding type defined in WSDL1.1 where
get,put, post etc can be captured as "verb" e.g. http:binding verb="GET

While REST based services may fit into a broader definition of webservices, a SOAP centric RPC styled
definition of Webservices is not suitable for RESTful services. Following page
compares SOAP and REST.
http://rest.blueoxen.net/cgi-bin/wiki.pl?HowSoapComparesToRest

Anyway, a comment suggesting a direction of using JAX-WS and a reference to "DL based on annotations" has stirred the developers
community. Particularly on a background where WS vs REST battle is still not yet completely
settled.

W3Consortium has published a presentation on reconciling Webservices and REST.
http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)



(Unofficial)Develoeprs Polls at
http://java.net/pub/pq/146 as of Feb 25th
Approve 126  34%
Disapprove 67  17%
no opinion 99  25%
wait and see 95 24%
other 7

Latest News: The JSR 
The Executive Committee for SE/EE has  approved this ballot.

http://jcp.org/en/jsr/results?id=4168

The next (tentative schedule)schedule:

February 2007	Expert group formed
June 2007	First expert draft
August 2007	Early Draft review
November 2007	Public Review
January 2008	Proposed final draft
March 2008	Final release.

Refereces:
1. JSR-311: http://jcp.org/en/jsr/detail?id=311
2. JAX-WS: http://java.sun.com/webservices/jaxws/
3. Restlest API: http://www.restlet.org/tutorial
4. Marc Hadley http://weblogs.java.net/blog/mhadley/
5. W3c on WS and REST: http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
6. SOAP and REST: http://rest.blueoxen.net/cgi-bin/wiki.pl?HowSoapComparesToRest

REST

JSR-311

Replacing XML with JSON in Ajax: Is it ready?

JSON (JavaScript Object Notation) is a data interchange format (based on subset of JavaScript Programming Language, Standard ECMA-262 3rd Edition), which is becoming popular alternative to XML in Ajax (Asynchronous JavaScript and XML) based software. It is comparatively lightweight than XML.

It has simple message format: JSON message is constructed using very simple data types and data structures similar to those available in most of the programming languages. JSON has objects and arrays. Objects are collections of Named value pairs while arrays are ordered lists of values. A value can be a string, a number, a boolean (true or false), null or an object. This message format makes easier for Ajax to access the data.

Ajax – JSON made for each other? A natural fit? Since Ajax itself is JavaScript based, JSON becomes a natural fit. You do not have to parse or evaluate JSON object within your Ajax code, you can immediately access the elements inside it. JSON object can be directly passed to JavaScript eval function. For example, var obj = eval( '(' + returned_json_text + ')' ) . This is fast and easy. Moreover, supported by most of the browsers and Ajax based tools.

Momentum: Though, neither JSON nor Ajax is conceptually new, in last couple of years both in general but Ajax in particular got a momentum. Ajax has provided a way to implement web based rich client. Ajax become mainstream with Google’s backing which provided Ajax based search (http://code.google.com/apis/ajaxsearch/) and toolkits (http://code.google.com/webtoolkit/). Other companies like Yahoo too entered quickly into the foray (http://developer.yahoo.com/maps/ajax/). In December 2005 Yahoo published JSON based web services (http://developer.yahoo.com/common/json.html) while Ebay provided XML2JSON transformer (https://json-xslt.codebase.ebay.com/).

Is it ready? While we witness a momentum, the real question is what do we need to make it end to end working? Do we have adequate tooling? What is the benefit? Is it worth? Is it robust? Secured?

While it does make sense for a browser based, in other words JavaScript based, clients to prefer JSON, the end-to-end applications need support from middleware and backend. In a typical scenario data goes back and forth through many layers between a database to a client. It gets mapped to the data structures on language implementing business logic; it may be converted to XML in a middleware. Before sending to the client it may need to be transformed to JSON. If the solution is dedicated to Ajax based client, then you do not need to convert from native to XML and then XML to JSON. You can directly serialize in JSON form. Jsontools (http://developer.berlios.de/projects/jsontools/), json-lib (http://json-lib.sourceforge.net), etc are some of the open source tools for Java-JSON conversion. JSON website (json.org ) lists many such libraries for different languages. You can use them. This path narrows your software to JSON/Ajax based solutions compared to XML based Web services provides a wide variety of applicability.

Over last decade, a much more mature and robust infrastructure has been build around XML. In contrast with it, most of these JSON based tools/libraries are open-source and, as of today, may not be well supported. You may use them at your own risk. That’s one drawback JSON has. It lacks tooling support and standardization for different language mapping. In Java world, do we need a JSR? However, I hope that some of these open sources may become Apache projects and start evolving towards standards or become de facto standard. It all depends on how much industry support JSON gets in Ajax world.

Security, and robustness are next issues that need to be addressed. Since JSON code may carry security risk particularly due to JSON text may carry Java scripts dynamic script tag. Heavy-duty JSON applications reveal browser specific issues like memory leaks.

In summary, there is a good promise with Ajax –JSON (additionally REST); you may start some internal pilot projects. However, it would need some more time and resources to mature JSON in this combination.

Introducing JSON: http://www.json.org/

Using JSON with Yahoo Webservices: http://developer.yahoo.com/common/json.html

XSLTJSON: http://www.bramstein.nl/xsltjson/

XML2JSON: http://code.google.com/p/xml2json-xslt/

XML2JSON: https://json-xslt.codebase.ebay.com/

JSON tools http://developer.berlios.de/projects/jsontools/

Json-lib http://json-lib.sourceforge.net

JSON

Basic assembly model of Service Component Architecture (SCA)

Service Component Architecture (SCA) specifications started as a joint effort by mainly IBM and BEA in 2004 soon got more acceptances in 2005 when other software companies like Oracle, IONA, SAP AG, Sybase, Xcalia and Zend also joined the effort. As of February 2007, seventeen key vendors (http://www.osoa.org/display/Main/Service+Component+Architecture+Partners) are working together to define a specification that can be a version 1.0. It has almost all major J2EE middleware vendors on its board. Offcourse, you won’t miss an absence of Microsoft.

Specifications:

Version 0.9 (Nov 2005)

http://www.oracle.com/technology/tech/webservices/standards/sca/pdf/SCA_AssemblyModel_V09.pdf

Version 0.96 (Nov 2006)

http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V096.pdf?version=1

Upcoming specification 1.0

A service, in case of web service defined in WSDL, is a heart of Service Oriented Architecture (SOA). Service can be implemented using different languages like Java, C++, PHP, etc and many follow different interaction protocols. Often services interact together to offer a business solution (thus becoming an application). However, there was no standard way to specific this dependencies and to assemble them together to form a composite application. Sun Microsystems had provided JBI to address some of the needs needs. However, JBI is Java centric. So cross platform component architecture was much needed. That’s where SCA stepped in.

SCA provides a way to specify the interaction of services and assemble them together to form a composite application. The specification does not dictate any runtime implementation but, just like WSDL is in XML, it express an assembly of a composite application composed of services implemented using different technologies like EJB, web services, C++, PHP and invoking internal or external services via different protocols. Thus making a deployable assembly of services. With this modular and uniform assembly of disparate services, platforms built on SCA would definitely provide service-based applications that are easy to deploy, configure, monitor and move. Thus, would reduce a Total Cost of Ownership (TCO).

Basics design blocks of SCA assembly:

Composite: As expressed in fig 1, a basic container block of SCA assembly is a Composite. A composite is composed of Services, entry points, references and wires linking them together. Composite is expressed in XML and it does not replace the definitional artifacts of software’s implementing the services. Composite has an entry point expressed as a Java or WSDL interface. These interfaces can be bound to different protocols like SOAP over HTTP, JMS, JCA, etc via bindings.

Component: One basic artifact of SCA is the component which implements services in using different implementations like BPEL, EJB, Annotated Java, and PHP etc. The implementation types are specified in the components definition. Services, implemented by components, can be consumed by other components and external software. The components may have settable properties.

References: Services provided by Components may depend on other services. The service depending on is specified as a reference.

Wires: Wires links components to references or other components.

Fig 1. SCA System assembly (source: SCA specifications)

Fig2. SCA Composite Assembly (source: SCA specifications)

Note that, though SCA assembly provides wirings between components and can be graphically depicted as a flow, SCA itself is neither an orchestration engine like BPEL nor a workflow.

Note that SCA assembly model provides a loose coupling and flexibility to change. You may notice that a referencing service need not know the implementation type of the referenced service. It only knows the interface. Similarly, one can always change the wires or bindings thus offering a flexibility. With this module composition of services and their implementation, we may see an overall increase of productivity.

All of these can be assembled together to make a composite as:

In addition to SCA assembly model, SCA defines specifications for client and implementations, bindings and policies.

Client and Implementation specs: SCA provides Client API and service implementation specifications (Java, PHP, BPEL, etc).

Bindings: Access interactions with outside a composite are defined by bindings. SCA specifications are working on various bindings like WSDL, JMS, RMI-IIOP, REST, etc.

Policies: SCA also working on defining a framework to define policies like transaction, reliable mesaging, secutity etc.

In some later posts, I would drill down further into more details...
SCA 2.0

What changed in WS-BPEL 2.0 from BPEL4WS 1.0/1.1

WS-BPEL (Web Services Business Process Execution Language) 2.0 is an execution language for Webservices based process orchestration. Currently (as of February 2007) it is in the final round of a public review to get accepted as a standard by Oasis (http://www.oasis-open.org/). With most of the leading vendors in middleware market being on its TC board, the specification published, on Jan 31^st 2007( http://www.oasis-open.org/committees/download.php/22036/wsbpel-specification-draft%20candidate%20CD%20Jan%2025%2007.pdf), is most likely to be accepted without any major changes.

WS-BPEL is the next revision of BPEL4WS (originally released on in July, 2002 and released as revision 1.1 in May 2003). Since there is an ample material covering some basic concepts of BPEL, in this article, I would mainly focus on some new features and concepts.

WS-BPEL clarifies the behavior of Abstract Processes. Abstract processes may hide (encapsulate) elements and activities of processes by replacing them by opaque entities or completing omitting those and, thus, becoming non-executionable. Abstract processes are useful to provide a common base with abstractions for further refinement, or identify matching counter process. Oh! This topic requires much more details, which can be covered in future. A New namespace xmlns=http://docs.oasis-open.org/wsbpel/2.0/process/abstract added for the better differentiation.

Process flow control activities:

WS-BPEL has following activities to orchestrate a process.

Activities interacting with internal/external entry to provide entry or exit points: receive, reply, invoke, pick

Data Related Activities: assign, validate

Data Related Activities: <assign>,

Process Flow related Activities: sequence, if, while, repeatUntil, forEach, flow, wait, empty, exit

Process Scope: scope, compensate, compensateScope

Fault Related Activities: throw, rethrow

Extension Constructs: extensionActivity

Out of these activities:

New activities: validate, repeatUntil, compensateScope, rethrow and extensionActivity.

Replaced Activities: switch changed to if - else, terminate changed to exit

Enhanced: onAlarm(add periodic),

Changes in: fault variable now declared catch, behavior of links changed.

Dropped: getLinkStatus() and getVariableData(). The functionality served by these functions can be achieved using new notations to access variables.

Data Handling:

Improved way to access message and variables:

WS-BPEL is XML centric. However, its earlier incarnation was not very friendly to Xpath and did not have XSL transforms. WS-BPEL further simplified Xpath mapping with a way to refer variables as “$variableName” in activities like assign, joins, etc. The same notation is used for property aliases too.

Transform: Most importantly, WS-BPEL has a function doXslTransform() to support XSL based transform. While giving a preferential treatment to Xpath, WS-BPEL still made a provision to support other mechanism with an attribute named expressionLanguage.For xpath,

expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"

Validate

WS-BPEL added an activity to validate a message. Additionally, assign activity has an attribute for validation.

Better mapping and exchange of message data:

BPEL process interacts with Webservices expressed in WSDL. WS-BPEL provides and constructs for easier copying BPEL variables to / from wsdl parts.

Additionally, WS-BPEL introduced a new construct called messageExchange to pair up concurrent and activities

Provision for extensions:

WS-BPEL introduced two constructs specifically for extensions. They are: extensionActivity and extensionAssignActivity. A new activity can be defined using these constructs.

Faults:

WS-BPEL has improved fault handling with Fault handlers having catch, catchAll, throw and rethrow constructs.

Process Termination:

The and exitOnStandardFault are added.

Process level addition:

At a process level, a support to has been added.

Also, a support to added to import WSDL and XSD within a process.

These are few high level changes. In addition to these changes, a much better clarification as well as some semantic changes is done in the existing constructs.

Topics like concurrent messages, compensation, fault propagation, abstract process etc needs more discussion. May be in a later blog…

References
1. WS-BPEL2.0 http://www.oasis-open.org/committees/download.php/22036/wsbpel-specification-draft%20candidate%20CD%20Jan%2025%2007.pdf
2. BPEL4WS 1.1:
http://www.oasis-open.org/committees/download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf
3. http://www.oracle.com/technology/products/ias/bpel/index.html

Service Virtualization

Service Virtualization or Service to service(s) map

In Service Oriented Architecture, a service definition, in case of web services expressed in a form of WSDL, is a contract between a service provider and consumer. This contract needs to be long lasting. Moreover, services needs to be well designed so that they can be consumed very well with various tooling and programming frameworks. It sounds easy especially when such services are defined in a standard language like WSDL.

However, when a provider is exposing a legacy application, like Peoplesoft Component Interface based application, as a service, it becomes often challenging because the services often carry signatures of legacy services including naming, data types etc. Consuming them becomes a nightmare because if you run then through some service developments tools like wsdl2java, you would get an explosion of java objects with meaningless names and a spaghetti object model. If the provider intends to expose such services at the same time re-implement the services, the provider would prefer to be a forward looking and should define the service contract as “how it should be” and not as “how it is today”.

Many air travel ticketing sites expose their web services and in backend use Web services from providers like Sabre as the actual provider. However, they may have some additional processing or just would like to hide the details of the actual provider service. In such scenario when a service provider is actually delegating to a third party, the provider would hide the identity and details of the third party service so that if needed it can be replaced by an in-house implementation or another third party implementation.

In many such occasions, service providers want to separate a service from its physical implementation. This usage pattern is often referred as “Service Virtualization” and would be served by a “service to service map”. Many Web Service gateways/brokers, Enterprise Service Bus like Oracle’s ESB typically provide a framework for virtualization.

In most of the implementations, the physical service may not be on the same host. The virtual service may have more meaningful or different names for service, operations and messages data types. Most importantly it may not have the same shape and it may even have a different protocol like SOAP over HTTP or JMS.

In bare-bone architecture of virtualization, there could be a one to one mapping of operations between a source and proxy service. In this mapping, the name of the operations as well as shapes of payload may get changed. In a more complicated scenario, a proxy service may represent a full or partial view of more than one service.

Thus, common Patterns of Service virtualizations are:

1. One to one: One service can be mapped to another service.

1. Fan out: One service operation can be delegated to multiple services to execute.

2. Partial: A service is partially exposed as a virtual service.

3. Aggregate services: Multiple services can be partially or fully grouped together and exposed as one virtual service.

A typical service virtualization framework would have metadata module to capture the service routing information, transformations and invocation framework to mediate between various transports.

In summary, Service virtualization is useful in following use cases

1. XML firewall isolating virtual and physical services

2. Proxy Service provider for an external service

3. Composite service from different services

4. Encapsulating legacy services

Service virtualization using Oracle ESB 10.1.3:

Here is an example of a 1:1 service virtualization using Oracle ESB 10.1.3. In this example I am providing MovieService as a proxy for an external movie service available on internet (http://www.ignyte.com/webservices/ignyte.whatsshowing.webservice/moviefunctions.asmx?WSDL)

The proxy movie service changes the namespace, and some operation name. The Routing service in ESB transforms and routes the incoming messages to the external movie service.

Higher level view of service virtualization:

Snapshot of Routing Service mapping to an external Service: