Apache Camel with Apache Tomcat provides a low-cost and lightweight integration framework. Is Apache Camel with Apache Tomcat a good fit for your project requirements?
All SOA infrastructure products should participate in managing, storing, deciding, or enforcing policy. More than a SOA Governance registry is required. Application Services Governance Platforms provides advanced policy management capabilities across design-time, run-time, security, and lifecycle management focus areas.
Policy management is a governance cornerstone, and governance can serve as a foundation underlying an responsive IT organization and business agility.
Governance relies on policy, people, process and technology to guide business activity and deliver consistently positive outcomes. Effective governance channels business activity towards the ‘right’ path by making the right actions the path of least resistance. Policy management is used to specify the correct behavior, detail exception thresholds, and define corrective actions or notifications. Leading application services governance platforms deliver advanced policy management by conforming to a flexible architecture, covering significant policy categories, and spanning all lifecycle phases.
As the technology discussion pivots to focus on APIs, teams are wondering how API and SOA converge. Are services simply being re-branded? Are APIs only good for mobile or external use cases? If we publish APIs, do we need SOA? Many architects believe that APIs do not apply to their projects or business use cases.
When you evaluate infrastructure vendors, do you correlate their agility and innovation with release velocity?
Many teams are actively refreshing their integration platform and evaluating open source ESB (Enterprise Service Bus) capabilities and benefits. Fewer are evaluating their SOA strategy and establishing open source SOA (Service Oriented Architecture) platform infrastructure, metrics, and measurements required to guide teams towards agility and responsiveness.
Progress Software recently unloaded Sonic, Savvion, and Actional to a niche enterprise software development company, Trilogy Software. Recognizing the poor brand fit between enterprise software development and enterprise application middleware, Trilogy will form a new entity, Aurea Software, to re-introduce the acquired portfolio into the market.
According to the press release, Scott Brighton, Aurea’s new CEO, will focus the company on a goal
“to take these market leading, enterprise-class products and place a renewed focus on creating the next generation iBPMS – with a specific emphasis on enabling critical, high-value business processes in key vertical markets.”
According to Jim Snur at Gartner, an iBPMS:
“allows organizations to have more intelligent processes that can be aimed at better operations minimally and innovative processes easily. The iBPMS does this by enhancing a businesses situational awareness by seeking patterns of interest, enabling quicker / more effective decisions through poly-analytics and rapid adaptation for appropriate actions through flexible processes”
An iBPMS focus is significantly different from the legacy standalone product lines focus on
- Develop high-quality, service-based applications
- Minimize downtime
- Service-oriented architecture (SOA) and enterprise messaging
- Rapidly and flexibly integrate services and applications across the enterprise
We will see if Progress’ decision to divest their on-premise integration portfolio was “the right thing for our customers and our partners that rely on them.” as stated by Progress VP Colleen Smith. How Aurea’s corporate focus will serve current customers using Sonic ESB or Sonic MQ as the cornerstone for their integration platform or SOA strategy remains to be seen. Whether development teams will embrace multiple best-of-breed vendors for iBPMS, aPaaS, iPaaS functionality also remains an open question.
- Develop an exit strategy and limit new investments in Sonic and Actional products
- Implement exit strategies and reduce integration project investment on Sonic and Actional products
WSO2 stands ready to assist you in migrate away from legacy products and embrace open source innovation. WSO2 is the only open source company that has been industry recognized for delivering enterprise-ready middleware platforms spanning integration, service oriented architecture, application, and business process platform. Enterprise development teams use WSO2 enterprise middleware platforms to build traditional on-premise solutions or incorporate Cloud service characteristics (i.e. on-demand self-service, elastic scalability, resource pooling, consumption based pricing) and Cloud service capabilities (i.e. DevOps tooling, automated governance, service level management, metering and billing).
An Enterprise Service Bus (ESB) may serve as the cornerstone of your Service Oriented Architecture infrastructure, or you may feel an ESB is unnecessary and cumbersome. Many integration projects contain simple requirements and use cases that warrant including an ESB, integration framework, or alternative platform components in the integration solution. Selecting the appropriate solution mix requires integration reference architecture guidelines that include a comprehensive decision matrix. Team members strive to avoid complexity and inefficiency by specifying an optimal platform component mix, defining ‘the right tool for the job’, and developing scalable, agile integration solutions.
Do you have clear architecture, solution, and ESB PoC guidelines describing how your organization can wisely select integration infrastructure components and products? Successful enterprise architects and solution architects create an integration reference architecture decision framework, ESB use cases, and product selection guidelines containing:
- ESB use cases driving integration platform component and integration framework selection.
- Common Request for Proposal (RFP) categories and line items.
- Tools describing when to include an ESB, integration framework, or alternative integration platform components (i.e. Data Services Server, API Manager, Governance Registry).
API management complements SOA Governance, drives service reuse, and maximizes Service Oriented Architecture success. Many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams. SOA governance programs often fall far short of encouraging consumer adoption, tracking service consumption, and illustrating business value. Too often, there is little or no insight into service reuse and:
- How to enable business functionality as an API
- Who is writing re-usable APIs and services
- Who is consuming APIs and services
- How APIs and services are being used
Can organizations perform API integration with no meetings? Moving at agile, startup speed requires auto-operations (auto-ops) and reducing human negotiations.
Can an eight year old product category, which is hotly contested by every middleware vendor, deliver unique and differentiating product offerings? When performing an ESB comparison, you will notice almost all Enterprise Service Bus products support enterprise integration patterns, deliver all required ESB features (i.e. web services, message transformation, protocol mediation, content routing), and offer a graphical development workbench. When technical evaluations focus on core performance and quality of service (i.e .reliability, availability, and scalability), proof of concept workloads must closely mirror expected production profiles and the evaluation effort ideally includes vendor participation.
In John Rymer’s recent blog post, Progress Software Lowers Its Sights, he breaks the news that Progress is divesting perceived ‘non-core’ middleware products. On the selling block are Progress Sonic ESB, Savvion BPM, Actional services management, and FuseSource. Progress’ recent strategy shift places Sonic ESB, Sonic MQ, and FuseSource implementations at risk of obsolescence. The list of probable acquirers could mean product termination and forced migration.
All Enterprise Service Bus (ESB) products may be used to build and deploy services, encapsulate legacy systems, route messages, transform message formats, and perform protocol mediation. Many WSO2 prospects ask me ‘What differentiates WSO2 Enterprise Service Bus?’ This blog post shares my perspective and scales the conversation.
Ten years after the rise of Service Oriented Architecture, many organizations have identified and published services as shared assets, however teams and partners often continue to invest considerable time and resources when building new solutions. Many teams experience rapid portfolio proliferation and sprawl, but not enhanced portfolio efficiency or business agility. Achieving business agility requires the growth of development partnerships and interactions, which should span both internal and external teams.
Traditional SOA and integration platforms enable rapid development, but they provide little business partnership support. Teams commonly operate independently and autonomously. Hundreds of people write new APIs and services; few people know:
- who is consuming APIs and services,
- who is writing re-usable APIs and services, or
- how APIs and services are being used.
You may have invested significant time and effort creating services. Have you reached maximum service agility, adaptability, adoption? Are applications now easier to build? Is it time for a SOA portfolio review?