• Create business processes from Web Services and Human Activities which span across organizations
• Create complex services from other less complex services from heterogeneous environments
• Create application integration flows from various existing and new applications based Web Services

In most cases we utilize the existing services available, to implement business processes. And there can be situations that those available services are secured using WS-Security.

WS-BPEL 2.0 specification doesn’t define a standard way of handling this type scenarios. And WS-BPEL handles the Web Services at the port-type level. So BPEL engine implementations has there own ways to handle this kind of situation.

We use Apache ODE in WSO2 BPS and we have separate integration layer written based on ODE-Axis2 integration layer. There is a slight difference between WSO2 BPS 1.1.1 and WSO2 BPS 2.0.0 when it comes to configuring WS-Security for partner services. In WSO2 BPS 1.1.1, user needs to create a separate file called package-config.xml which contains endpoint configuration information while in 2.0.0 we have extended deploy.xml to support these configuration. But both these mechanisms share same configuration elements and only difference is the place we keep them.

Users can use Policy XML compatible with Apache Rampart or services.xml file which compatible with Axis2 and contains security policies compatible with Rampart to configure WS-Security for partner services.

How to configure security for partner endpoints?

WSO2 BPS 1.1.1

You need to create a separate file called package-config.xml which looks like following, and put it in the root of your BPEL package.

In this package configuration file we have ‘endpoints’ element which contains configurations of all the endpoints exposed by BPEL process and invoke by BPEL process. When configuring endpoints you need to specify serviceName, servicePort and serviceNS attributes according to the configurations in deploy.xml. For example if you want to call secured CreditRatingPL partner link(CreditRating service partner service) in following deploy.xml file, endpoint configuration will look like above example.

To configure security you can use either a policy XML or services.xml file. And policy configurations are same as configuring security for normal Axis2 based service clients using Rampart. There are Rampart specific policy extension elements which let you configure key stores, user name – password pairs and password callback classes.

You can put the policy XML files and services.xml files in BPEL package or in anywhere in the file system and put the correct location in location attribute. If your password callback classes are in a separate JAR, you can put them on the BPS_HOME/repository/components/lib directory.

You can download sample BPEL package for WSO2 BPS 1.1.1 which shows you how to configure security from here.

WSO2 BPS 2.0.0

The main difference in version 2.0.0 is you can specify security and other endpoint configuration parameters directly in deploy.xml file. For example to configure security for CreditRatingPL partner link, you can directly specify endpoint configuration inside ‘service’ element as follows. In this case you don’t need to specify service name or port name, because they are already available in the parent element(‘service’).

You can download sample BPEL package from here.

Resources

• Secure Web Services with Apache Rampart
• Rampart FAQ blog

• BPEL4People and WS-HumanTask Support(Experimental)
• Instance cleanup scheduled task for production deployments
• Component manager to install and uninstall features (provisioning support)
• External service invocation via JMS
• XPath extension support

in addition to various bug fixes to underline BPEL engine(Apache ODE). You can download new release from Oxygen Tank’s download page.

To facilitate requirements like above, our middleware must be cloud-native. But, how can we know middleware tools out there are cloud-native. WSO2 CTO, Paul Fremantle, recently composed a blog post containing core attributes that each cloud-native middleware must possess. Following are the core attributes of cloud-native middleware according to Paul.

• Distributed / dynamically wired
• Elastic
• Multi-tenant
• Self-service
• Granularly metered and billed
• Incrementally deployed and tested
  

In addition to above attributes, I think that cloud-native middleware or any other application must have the capability to use existing services provided by different cloud vendors and cloud-native middleware must be cross-cloud compatible.

But , it’s a hard thing for vendors, when it comes to cross-cloud compatibility and utilize the existing cloud services. The best solution for this is to come up with a standards for services provided by cloud infrastructures. But, standardizing cloud services will not going to happen near future, because of the current competition and nature of different cloud infrastructures.

At WSO2, our team is working hard to build the cloud-native SOA platform. So be prepared to experience the cloud-native middleware platform.

Most in the SOA community understand that data services provide controlled interfaces to underlying data, but typically don’t understand the strategic value of data services to the SOA.

He emphasized the fact that those who focus on the notion of a service as delivering functional behavior, neglect the need to manage the underlying data. He tells that

In many cases, data quality and consistency issues quickly arise, and the agility that SOA should provide is limited by the need to alter services directly after the underlying data has changed.

David argues that data services created and leveraged correctly within the context of a SOA, should provide a wide variety of features including data quality assurance, data governance, and, most importantly, the ability to support data abstractions.

Even though there are lot of benefits(David’s opinion is further elaborated by Ash Parikh), getting data service right is not an easy task. You need to consider about the design, implementation, technologies and tools you are going to use for this. You can find several guide lines and best practices in designing and implementing data services from articles “Introduction to Data Services“, “Incorporating Enterprise Data into SOA” and “How To Get Started with Data-Orientation – What Architects Told Me…“.

Even you get the concepts and your designs correct, you must find a tool which allows you to incorporate you design and best practices into the implementation in flexible and easy manner. There are so many tools out there which provide support for developing and deploying data services written following various standards. In this post I am going to introduce you to the WSO2 Data Services Server, which is a award winning product from WSO2.

WSO2′s award winning Data Services solution WSO2 Data Services Server is a data services solution that will help you to achieve your targets in data orientation.

With the recent 2.2 release WSO2 Data Services Server provides some major improvements to it’s industry leading data services solution. Following new features are included in this release.

• Support for large XML outputs – The core engine has been modified to support XML streaming. This has resulted in two notable improvements.
  • Efficient use of server memory – No matter how large the payload is, server memory does not grow propotional to it. The streaming capabilies push data to client side as and when needed
  • Improved response time
• Google Spreadsheets as a data source
• Content filtering based on user roles
• Support for named parameters
• Ability to configure schema type for output elements
• Mixing multiple data source types in nested queries
• Excel 2007 support
• Support for Oracle Ref Cursor – Oracle Ref cursor is a Data type. A variable created using this data type is usually called as a Cursor Variable. Some of the primary advantages of using a ref cursor are,
  • ability to pass resultset between sub programs (eg: functions, stored procedures)
  • dynamic queries
  • efficient memory utilization

For more tutorials on WSO2 Data Services Server visit wso2.org.

Service oriented architectures (SOA) are currently a hot topic and touted as a key to business agility and solution to a most problems in enterprise information systems. But the success of SOA is totaly depending upon the alignment of purpose and objectives between IT and business. In their latest article, IBM’s Jens Andexer and Willem Bekker from Standard Bank provide some sample of the good, the bad and the ugly business aspects of SOA.

They have divided impact on business by SOA into several categories and described the pros and cons of each.

Agility

• The good: Two main concepts behind SOA are reuse and loose-coupling. By reusing existing applications you can create new applications. And by applying loose-coupling you can minimize the impact of change, and therefore it’s easier to adopt your software to changing requirements. So SOA allows organizations to reduce time to time to market and adaptability and this will increase competitiveness of your organization.
• The bad: Requirement of introduction of new entity(Center of Excellence) which provides technical expertise to the rest of the organization can leads to conflicts among the different sections of the organization.
• The ugly: Transforming organization to become service oriented can be complex and expensive. In addition to that there is no shortage of opponents to the change.

Alignment

• The good: Alignment of IT functionality to business functionality and describing IT functionality in business terms, SOA facilitates a closer collaborative relationship between business and IT.
• The bad: Placing the ownership and control of services into the domain of business changes the power structure in organizations. This is typically met with resistance from those who have a vested interest in keeping the status quo.
• The ugly: Implementing SOA in your organization not only require change in technology aspects, it also require change in organization structure and culture. The organization must learn what is meant by agility and how to effectively use SOA. the ugly truth is that this is the one of the difficult lesson to learn.

Business Process Improvements

• The good: When applying SOA to your organization, it involves business process re-engineering. This will help organizations to improve their existing business processes.
• The bad: When implementing SOA, business must involve in defining services and designing of the IT systems. This is not the typical role played by the businesses and it’ll become uncomfortable change.

Flexibility

• The good: Good software engineering practices enforced by SOA will make IT to be more responsive to the changing business needs.
• The bad: Introduction of services make complexities of the IT a secret. But on the other hand SOA implementations typically depends on the set o technologies like business process execution engines, ESBs and etc.
• The ugly: An SOA initiative is founded on the promise of delivering business value quicker and cheaper than before. But SOA that is too technology focused is unlikely to deliver on that promise since they will not show value in terms business people want to see it.

Data Unification

• The good: Interoperability is a aspect of SOA. The design of inter-operable service interfaces provides an opportunity for data unification across enterprise IT systems. Unified here means common:
  • Structure – the structural relationships between elements is the same
  • Semantics – semantic refers to the meaning and use of the data. Data must have a consistent meaning and must not be used in a way that can be misleading
  • Format – how data is represented is important
  • Type – A type is determined by the representation of data and the set of behavior that can be performed on it
  • Timing – Timing refers to when an attribute is updated
  • Life cycle – under what circumstances data is add to data bases and when it is updated and when and how it is finally deleted from data bases
• The bad: Typically this type of data unification doesn’t exist. Trying to develop it often shows how disparate views in the organization may be.
• The ugly: It hard to address all the characteristics of consistent data and the ugly truth is that unifor service interface is very difficult to build.

Operational Monitoring

• The good: The technologies and principles used to enable a SOA make monitoring business process easier. This allows organizations quickly adopt their systems to meet their business goals.
• The bad: But building a system that can actually provide valuable outcome requires specialist skills.

Leveraging Operational Systems

• The good: In most scenarios SOA use existing systems to supply the business functionality to services. This will reduce the costs while allowing organizations to use their money for further improvements in their businesses.
• The bad: In some cases it’s hard to repackage existing systems in to services.
• The ugly: In some cases operational systems may need to be changed or additional logic/implementations might be required.

Summary

“For SOA to be a success, business and IT must align there purpose and objectives. IT driven SOAs fail because they are perceived as a change in technology that has no direct benefit to business. The case for SOA must strengthen the organization’s existing goals and strategy and this goes beyond an IT centred approach. This represents a culture change to where business expectations drive the priorities for IT which when coupled with a culture of co-operation between business and IT lays the ground work for success.”

Via InfoQ.