What's New in SOA and Web Services?

   
By Ed Ort, October 3, 2005  

Articles Index

Contents
 
Registry/Repository
Federated Identity
Portal Access to Web Services
Additional Capabilities
For More Information
 
 Painless SOA
You can use Sun Java Studio Enterprise to build effective web services. Sun Java Studio Enterprise frees you to focus on business logic because it handles the low-level details of web services, such as SOAP and WSDL, with time-saving wizards and test clients.

Service-oriented architecture (SOA) -- especially web services-based SOA -- has been the talk of the IT community. It's almost impossible to discuss corporate technology plans or strategies without discussing SOA. That's because many IT professionals see SOA as a way to speed up the application development process. They also see in SOA a way to become more agile and more adaptable in responding to changing business needs. A previous article introduced SOA and web services concepts, and described the basic technologies and tools available to implement a web services-based SOA.

With these technologies and tools, companies are already starting to build applications based on an SOA approach. For example, RouteOne LLC, a credit aggregation management company for the automobile industry, implemented a web services-based SOA project that resulted in dramatically streamlining and speeding up a number of vehicle financing software applications for car dealerships. You can read more about this in The Next Big Thing: Service-Oriented Architecture (SOA) Takes a New Route.

Clearly, the basic underpinning required to implement a web services-based SOA is available. But companies are also looking for enhanced capabilities that will help them not only more easily create and use web services, but also help them manage and secure web services within an SOA. The good news is that some of these enhanced capabilities are beginning to emerge as new or enhanced technologies, and they're starting to be supported in infrastructure software and tools. Sun is a leading software provider in this area, with a well-defined initiative to enable and simplify SOA. As part of this initiative, SOA-specific features are being phased into new releases of Sun Java Enterprise System, Sun Java Studio Enterprise, and other Sun products.

 

Companies are looking for enhanced capabilities that will help them not only more easily create and use web services, but also help them manage and secure web services within an SOA. The good news is that some of these enhanced capabilities are beginning to emerge as new or enhanced technologies, and they're starting to be supported in infrastructure software and tools.


Pragmatic SOA

Underlying Sun's initiative is the concept of "pragmatic SOA." This means that companies taking an SOA approach should be able to put it into practice incrementally, as easily as possible, and in a way that generates a quick return on investment.

Rather than taking a "rip and replace" approach by eliminating existing software assets such as legacy applications and replacing them with new services, the pragmatic SOA approach calls for making existing software assets available for reuse by wrapping them with appropriate web services interfaces. Of course, developers can build new services from scratch to augment existing applications, and tools are emerging to simplify this. Click here for more information about pragmatic SOA.

 

The enhanced capabilities include the following:

  • A service registry/repository
  • Support for federated identity
  • Portal access to web services
  • A framework for composite services
  • Tools to manage service orchestration
  • Faster web services
  • Simplified service creation and consumption
  • Advances in web services technologies

This article introduces you to the first three of these enhanced capabilities and the emerging technologies, tools, and infrastructure software from Sun that provide them. The article also points to places where you can get more information about these topics. Table 1 at the end of this article briefly summarizes the other enhanced capabilities. Future articles in this series will provide more detail about these additional capabilities.


Registry/Repository
Figure 1. Registry/Repository

Your enterprise starts implementing SOA projects. You start making existing applications available as web services, and you also create new web services. You start building applications that use these web services. You might also want to use web services that are outside of your organization, perhaps web services that your business partners offer.

How do you find the web services you need outside of your organization? How do other organizations find your web services? How do you or anyone else know how to access the web services they find? The answer is a service registry.

Service registries are a standard part of SOA. The initial service registry implementations typically conformed to the Universal Description, Discovery, and Integration (UDDI) standard developed by the Organization for the Advancement of Structured Information Standards (OASIS). In essence, a UDDI registry is a set of yellow pages for web services. Like the yellow pages business directory, a UDDI registry entry provides information about services -- in this case, web services.

A UDDI registry entry provides information such as the service's name, a brief description of what the service does, and an address where the service can be accessed. It also points to a Web Service Definition Language (WSDL) file that describes the interface to the service. UDDI registries work well as a way of advertising and finding services.

But many SOA projects, especially those that involve collaboration between different organizations such as business partners, require registries that are more comprehensive than UDDI registries. They need a way to share not only the kind of basic information that's in a UDDI registry, but also information such as business processes and security policies. That is where the ebXML Registry Standard comes into play.

ebXML is a comprehensive business-to-business framework for electronically-based business collaboration. The framework was developed as part of an initiative that combined work by OASIS and the United Nations/ECE agency, CEFACT. A key part of the framework is the ebXML Registry standard. The standard provides a registry for publishing and discovering services, as well as a tightly coupled repository that holds artifacts related to the services. This allows businesses to publish and discover services and to share additional information about those services with their collaborating partners (see Figure 1). Although the artifacts can include any content, in a business collaboration scenario, the content is likely to include things such as business processes as described in Business Process Execution Language (BPEL) files, security policies, XML schemas, Web Services Description Language (WSDL) files, and XSL Transformation (XSLT) stylesheets.

The need for an integrated registry/repository becomes more pronounced as companies get more heavily involved in SOA. As they implement more SOA projects and as the deployments become more complex, companies are finding that a registry is not enough to publish and discover the information needed about services. The contents of a registry and an associated WSDL file provide a base of information about a service, but often other information is needed, information stored in artifacts outside of the registry.

For example, if a service is a composite of services that needs to be orchestrated in a way that mirrors a business process, it's important to know what that process is. That type of information is often provided in a BPEL file. Or if a service is accessible to portals, it's important to know how the service can be used by a portal. That type of information is provided in a Web Services for Remote Portlets (WSRP) description. (See the Portal Access to Web Services section for more on portals and SOA.) BPEL files and WSRP portlet descriptions are some of the types of artifacts that can be stored in a repository within an integrated registry/repository that conforms to the ebXML Registry Standard.

Beyond the need for more fully capturing information about a service, an integrated registry/repository gives companies a central point of control for an SOA. Companies need a way to track and manage services and related service metadata and artifacts in a way that's consistent with company policies and rules. For example, a company policy might require that all service bindings must be SOAP bindings and that only document style can be used for service communication. Because it holds both the metadata and artifacts for a service, an integrated registry/repository makes it easier for companies to validate that all WSDL files specify information that conforms to that policy. This management of services in conformance to company policies and rules is often termed SOA governance.

What's New?

What's new and significant in this area is the latest version of the ebXML Registry Standard, ebXML Registry 3.0, and a new registry/repository, the Sun Service Registry, that supports the new level of the ebXML Registry Standard. The Service Registry also supports the newest level of the UDDI standard, UDDI 3.0. The Service Registry is integrated into Java Enterprise System 2005Q4 (hereafter, this article will refer to Java Enterprise System 2005Q4 as Java ES Release 4). Sun Java Application Server 8.1, which is also integrated into Java ES Release 4, provides a default container for the Service Registry.

By supporting ebXML Registry 3.0, the Service Registry provides a centralized registry and tightly coupled repository. This allows companies to register their services, and to store and manage metadata and artifacts associated with those services, such as BPEL files, security policies, XML schemas, WSDL files, and WSRP remote portlet descriptions. In addition to providing for a combined registry/repository, ebXML Registry 3.0 adds a federation feature. This enables multiple registry/repositories to logically join together so that they appear as one virtual registry/repository. Each registry/repository in the federation is managed by its owning organization, but the entire federation is accessible as one registry/repository. This allows businesses to do federated discovery across registries. In other words, a business can use a single ebXML or UDDI query to discover services and related metadata and artifacts in the Service Registry as well as in other registries in the federation.

Federation underscores the importance of having a registry/repository that conforms to an open standard such as ebXML Registry. Conformance to that standard enables the seamless integration with local control associated with federation. Beyond its support for registry and discovery, the Service Registry also has some important SOA governance features that enable a company to specify and enforce policies that regulate the content and use of services, service metadata, and artifacts. For example, the Service Registry includes security features that control access to artifacts based on user roles, as well as features for validating and organizing artifact content.

Why Is This Important?

The Service Registry is not only a registry solution, it's also a cornerstone of SOA governance. It gives companies a registry/repository for publishing and discovering needed information about services, that is, metadata and related artifacts (in fact, supporting federated discovery). Just as impotantly, it gives companies a centralized way of tracking and managing its services and related content based on things like life-cycle stage and organization policies.

For More Information

See the Sun Service Registry.

Federated Identity
Figure 2. Components in a Federated Identity Scenario

Services in a network can be almost anywhere -- whether in different departments within a company, in different companies, or in different countries. Each can have its own safeguards or lack of them. In such a network, the opportunity to disclose sensitive information to the wrong people is heightened. Thus, maintaining security in an SOA, which brings together services in a widespread and networked way, is vital. Enterprises that implement an SOA are demanding end-to-end security, where the entire chain -- from service requester to service provider and any intermediaries -- are secured. Unfortunately, because different departments and organizations tend to implement security mechanisms in their own unique way, providing end-to-end security can be extremely complex.

One aspect of providing security is authenticating identity: ensuring that the requester of a web service -- whether a person or a piece of software such as another web service -- is who he (or she or it) says he is. After the requester's identity is established, the access control system in place for the service must determine whether the requester is authorized to use the service. A typical way to authenticate identity is to have the requester log in with a user ID and password. This requires the requester to log in for each unique service. Although this might be reasonable for a small number of services, it can quickly become unworkable for a larger set of services, particularly if each has different rules regarding login.

This has stimulated the need to implement a single sign-on approach and federated identity. In a single-sign on approach, the requester logs in only once. Different services in an organization can then use that login information to authenticate the requester's identity. Based on that information and related information such as a requester's job role, the requester does (or does not) gain access to the service.

 

Asking a requester to log in for each service request might be reasonable for a small number of services, but it can quickly become unworkable for a larger set of services, particularly if each has different rules regarding login. This has stimulated the need to implement a single sign-on approach and federated identity.


Federation and Federated Identity

The terms federation and federated identity can sometime be confusing. Here are their definitions:

Federation: The agreements, standards, and technologies that make identity and entitlements portable across autonomous domains.

Federated Identity: An association between identities in different domains. A federation must be in place before federated identity can be implemented.

Federated identity extends access control and the single sign-on approach across Domain Name System (DNS) domains so that different companies (such as business partners) in different and autonomous domains can handle authentication across those domains in a trusted way. In other words, Partner B trusts Partner A to authenticate a requester in Partner A's domain and to attest that the requester is authorized to access the services in Partner B's domain. This trusted relationship requires that the participants have established an agreement to enable such a relationship.

Two cornerstones of federated identity are the Security Assertion Markup Language (SAML) and the Liberty Alliance Project. SAML is an XML-based standard developed by OASIS for exchanging assertions. An assertion is an XML construct that can contain statements about authentication, authorization, and attributes related to a subject, where a subject is either a person or a computer. An authentication assertion validates the subject's identity. An authorization assertion specifies what the subject is allowed to do at a particular site. An attribute assertion contains specific information about the subject. SAML also identifies profiles that specify the mechanisms for exchange of assertions and the roles that interact during the exchange.

The Liberty Alliance Project is an effort by a consortium of over 170 organizations to address issues related to identity and identity based-web services. A major goal of the Liberty Alliance is to come up with a set of open standards for federated identity management. And so, the alliance developed Liberty specifications for federated identity. The initial level of the specifications (known as Phase 1) built on SAML and extended it. One of key elements of the Phase 1 specifications is the Identity Federation Framework (ID-FF), which enables single sign-on across autonomous domains, and allows for account linking between partners with established trust relationships.

Phase 2 of the Liberty specifications added the Identity Web Services Framework (ID-WSF) and Identity Services Interface Specifications (ID-SIS), which together provide for adding web services to a federated identity environment.

These specifications allow users to link identity information and credentials (such as user name and password) across federated domains. In an SOA context this allows a service requester that has an identity in two domains to authenticate in only one domain and then use its associated credentials to access a service in the other domain without having to reauthenticate.

What's New?

SAML 2.0 was recently approved as an OASIS Standard. An extension of version 1.1 of SAML, it now incorporates ID-FF. This is an important first step towards the convergence of the SAML and Liberty Alliance standards for federated identity. Also, a new specification, Java Authentication Service Provider Interface for Containers (JSR 196) is making its way through the Java Community Process. It defines a standard service provider interface for authentication service providers so that their authentication modules can be integrated into a Java Platform, Enterprise Edition (Java EE, formerly known as J2EE) container in a standard way. Implementation of this specification will insulate developers from the mechanics of ID-WSF.

Sun Java System Access Manager, an important component of the Java Enterprise System, has long supported both SAML 1.1 and the Liberty Alliance Project standards (ID-FF 1.2, ID-WSF 1.0, and ID-SIS 1.0) for federated identity (in fact, it was the first implementation of this functionality). The newest release of Access Manager (7.0) is tightly integrated into Java ES Release 4. Support for federated identity is also provided by Sun Java System Federation Manager, a low-cost solution for federated services. Java System Federation Manager is currently available as an early access release.

Why Is This Important?


 

A Federated Identity Scenario

What would federated identity allow an organization to do? Let's consider one scenario.

A company named ABC Circuits that manufactures electronic circuit boards has a company portal that its employees use for various services. Another company, CMT Chips, is an electronic chip manufacturer. One of CMT Chips's customers is ABC Circuits. Both companies have their own identity management systems.

Through Access Manager and its support for federated identity, ABC Circuits employees who have the established role of purchasing clerk can use their company portal to order chips from CMT Chips, and they can do it without having to specifically authenticate in the CMT Chips domain. In other words, they don't have to log in to CMT Chips. Nowhere in this scenario is the real identity of the purchasing clerk revealed to ABC Chips.

 

For More Information

See Federated Identity, Access Control, and Single Sign-On Resources.

Portal Access to Web Services
Figure 3. A Company Portal

So far this article has covered what's emerging to aid in managing an SOA, but what about features that simplify using services in an SOA environment, particularly the delivery and access --what some call consuming -- of those services by end users? What about features that simplify bringing together a variety of services for use? Actually, some important things have been happening there too. One important advance is the increasing use of portals as a means of consuming services in an SOA. Notice that in the CMT Chips scenario, the user accesses the CMT chips web service through a company portal.

A portal is designed to aggregate and present information from different applications and content sources in a personalized and secure way. It can do so through almost any access mechanism, including mobile devices. For example, a company portal might present a web page that brings together applications of value to its employees, such as a company news feed, a company telephone directory, a directory of company services, and human resources applications such as a vacation scheduler and benefits planner (see Figure 3). As shown in the CMT Chips example, portals can also be a platform for exchanging information between business partners such as a customer and suppliers.

Two important characteristics of a portal are that the origin of the data that it presents can be anywhere, and that the portal personalizes the presentation of the information for the user. In other words, two users having different roles in a company might see very different views of the same portal. This customization is handled by the portal aggregation and personalization framework, and it is also handled at the portlet level. A portlet is a fragment of a portal. More specifically, it's a component that renders a markup fragment that represents an application or content view that a portal can display in aggregation with other such views. Typically the output of multiple portlets are combined to produce the portal desktop display.

Creating and managing portal sites and their portlets are portal server products such as the Sun Java System Portal Server. Over the past few years there has been work done to standardize portal interfaces so that portlets developed for one portal server can be deployed onto other portal server products. That standardization effort produced the Java Portlet Specification (JSR 168), which defines the portlet API for writing industry-standard pluggable user interface components. JSR 168 is a specification for creating portlets that can be deployed locally onto a portal for aggregation, that is, where the portlet and the portal are in the same environment.

Complementing JSR 168 is the Web Services for Remote Portlets (WSRP) specification, an OASIS standard that specifies a protocol and interfaces for enabling remote portlets. A remote portlet is a portlet that's deployed in a different environment than the portal that actually uses it. WSRP specifies a standard way for local portlets to be exposed through web services so that they can be consumed by other portals.

What's New?


It's important to note that WSRP enablement is built into the Java System Portal Server, so that once a JSR 168-conforming portlet is developed and deployed in the Java System Portal Server, no additional programming needs to be done to make it remotely available. Neither is any programming required to make a portal consume remote portlets. This makes portals managed by the Java System Portal Server particularly attractive platforms for SOA. The Java System Portal Server also provides built-in support for consuming data-oriented web services by automatically generating user interfaces that allow the end user to interact with those services. This allows the consumption of services that are not inherently or natively visual.

 

WSRP enablement is built into Java System Portal server, so that once a JSR 168-conforming portlet is developed and deployed in the Java System Portal Server, no additional programming needs to be done to make it remotely available. Neither is any programming required to make a portal consume remote portlets. This makes portals managed by the Java System Portal Server particularly attractive platforms for SOA.


Also emerging are tools to simplify building portlets. For example, Sun Java Studio Creator 2, which is now available as an early access release, provides a visual way to create and design portlets. Portlets that are created using Java Studio Creator 2 and deployed to the Java System Portal Server can be automatically enabled as a remote portlets. This makes Java Studio Creator 2 an excellent tool for building portlets that interface with web services. For more information about creating portlets with Java Studio Creator 2, see Creating Portlets in Sun Java Studio Creator.

Role-Based Content Delivery in Portals

One of the important features in the Java System Portal Server is role-based content delivery. Essentially what this means is that what a user sees in a portal is controlled by policies in the user enterprise.

In this scheme, a portlet developer designs a portlet as a set of tabs, subtabs, and frames, and deploys combinations of these elements, as appropriate, to different organizations, suborganizations, and roles in the enterprise.

The Java System Portal Server then delivers the content for each portlet to an individual, as authorized, based on his or her individual role. Role-based content delivery complements WSRP so that companies can use Java System Portal Server to easily implement a role-based SOA.

There are also intersections between the new Service Registry and the emerging use of portals for SOA. Before a portal that acts as a WSRP consumer can access a remote portlet, it needs to find the producer's WSDL. That WSDL, as well as other artifacts related to the producer, can be registered by the producer in the Service Registry and made available for discovery by the consumer. Upcoming versions of the Java System Portal Server will provide additional support for publishing, managing, and discovering WSRP producer and remote portlet descriptions in the Service Registry.

Why Is This Important?

Leveraging web services through portals by means of the Java Portlet and WSRP standards gives companies a relatively easy way to begin implementing an SOA. And the built-in support for the Java Portlet API and WSRP in Java System Portal Server makes implementing a portal-based SOA even easier. Beyond that, portal support for the Java Portlet and WSRP standards, allows companies to easily create and offer SOA-style services to other parties. These other parties can combine several of these visual services from diverse sources to form the visual equivalent of composite applications. This approach delivers entire services to the other party so that the services can be conveniently consumed and used without any programming effort. For these reasons, a portal-based SOA -- particularly one managed by Java System Portal Server -- is a good initial SOA implementation project for a company.

For More Information

See Portal University.

Additional Capabilities

Other enhanced capabilities are emerging in support of SOA. Table 1 summarizes what's new regarding these new capabilities. Future articles in this series will cover these emerging capabilities in more depth.

Table 1. Additional Capabilities Emerging in Support of SOA
 
 
Capability
What Is It?
What's New?
For More Information
Composite services
A higher-level service that is composed of other services. Typically a composite service performs a set of business operations that collectively represent a multiple-step business process.
The final release of the Java Business Integration (JBI) specification, JSR 208 is available, as well as a reference implementation. JBI provides an extensible, pluggable, and (most important) standardized, framework for vendors -- specifically integration server vendors -- to create business integration solutions. In a more general sense, JBI provides a framework for constructing composite services.
Service orchestration
A means of getting the services in a composite service to run in the correct order (generally to follow an actual business process).
Features are emerging in developer tools to simplify business process modeling and the orchestration of services that implement these business processes. These capabilities will be built into Java Studio Enterprise 9. A preview of these business process modeling and service orchestration features will be made available soon.
Faster web services
Better web services performance.
Fast Infoset, a binary data format for message transmission that's an alternative to XML, is now available in the Java Web Developer Pack (Java WSDP) 1.6. Fast Infoset is designed for fast message transmission between services. It can increase processing speeds up to four times or more as compared to XML. When the Java WSDP 1.6 plug-in is installed in the Sun Java System Application Server 8.1, users should see significant service performance improvements.
Simplified service creation and consumption
Easier ways to create services and applications that consume services.
The release of NetBeans IDE 4.1 brought new features for creating and testing services, features that are now part of Java Studio Enterprise 8 (currently available as an early access release). Services can also be consumed using Java Studio Enterprise 8, Java System Portal Server, and Java Studio Creator. The early access release of Java Studio Creator 2 is now available. It provides a visual way to create and design portlets. Portlets that are created using Java Studio Creator 2 and deployed to the Java System Portal Server can be automatically enabled as a remote portlets.
Advances in web services technologies
Additional SOA-related functionality provided by web services technologies.
Extensions to web services technologies are emerging. The recently released Java WSDP 1.6 includes an early access release of XML and Web Services Security (XWS-Security) 2.0, which adds a number of security enhancements such as support for attachment security. Beyond the enhanced technologies in Java WSDP 1.6, even more advanced versions of Java technologies for web services are now available as early access releases on java.net. The new stack includes version 2.0 levels of Java API for XML-Based Web Services (JAX-WS, formerly known as JAX-RPC), which supports optimized transmission of binary data; and Java Architecture for XML Binding (JAXB) 2.0, which adds support for metadata-based marshalling and unmarshalling of XML and Java technologies. This makes the marshalling/unmarshalling process more seamless.

 

For More Information
Rate and Review
Tell us what you think of the content of this page.
Excellent   Good   Fair   Poor  
Comments:
Your email address (no reply is possible without an address):
Sun Privacy Policy

Note: We are not able to respond to all submitted comments.