Broadcasters no longer have the monopoly on the delivery of A/V entertainment to the home. In the fiercely competitive world of media and entertainment, companies have to deliver more versions and formats, but without increasing their costs. A channel is now expected to have a Web presence, as well as mobile and tablet versions of their content.
Organizations like the EBU and Advanced Media Workflow Association (AMWA) are promoting the service-oriented architecture (SOA) as a route to provide the interoperable media services that can serve the new business requirements.
For the seasoned video engineer, the world of SOA introduces terms and concepts that at first encounter seem foreign and more suited to the IT specialist. As video processing migrates to the file domain, there is no option but to become familiar with what at first sight may appear alien.
Broadcast systems have evolved around the imposed workflow of the serial processing steps of videotape operations. Over time, many processes have moved from dedicated hardware boxes with SDI in and out to software applications on a network. A typical broadcast operation is now a hybrid of SDI and IP connections.
In many cases, the workflow remains as the original tape-based flow. Over time, other applications like asset and workflow management are layered over the entire process chain. The system has grown by accident, not by design, and become a web of custom or proprietary interfaces linking the many applications.
Sure it works, it was designed that way, but when the time comes to replace a component part — say the playout automation — the inflexibility of the system rapidly comes apparent. The parts of the system are linked by a web of custom APIs, often restricted to a specific release of a specific software application. It is just not possible to swap out the automation for the latest product without attending to the web of interfaces.
To meet the demands for new services to the public, the broadcaster must add facilities for a mobile news service, a 3-D channel and interaction with a social media website. Along comes CES and some new consumer device to consume content. How do you add support for this new device? Will it mean more custom interfaces or more special workflow applications? The EBU and AMWA are developing a Framework for Interoperable Media Services (FIMS), which aims to provide a new technology platform that leverages current IT practices, like the use of the SOA, to provide business agility and to control costs.
Gartner has estimated that over 80% of data exchanged between organizations are transfered via files such as office documents, PDF, CSV, media files, and for the majority of our customers it’s: check images and financial transaction files.
Managed File Transfer (MFT) solutions, like Flux, orchestrate automated file transfers between departments and business partners in a secure fashion while providing:
- Monitoring: Central web-based monitoring console.
- Notifications: Email, SMS, JMS, etc.
- Automatic Error Handling: Automatic handling of failures: send an email and retry the transfer.
- Reporting: Web-based reporting and auditing.
- Enterprise Integration: Integration with web service APIs (SOAP and REST) and 3rd party enterprise applications such as Cognos and Informatica.
This is an API for the development of soap web services using the python programming language and tornado web server. The goals of this api is provide an simple and easy way of develop and deploy soap web services.
ProcessMaker is a very unique enterprise-grade Open Source business process management (BPM) and workflow software designed for small and mid-sized businesses (SMBs) and organizations.
ProcessMaker is written in PHP and Ajax, fully web-based with a service oriented architecture.
The European Broadcasting Union (EBU) and the Advanced Media Workflow Association (AMEA) are to demonstrate some early capabilities of Service Orientated Media Workflows at this year's NAB show being held in Las Vegas in a little over one week's time.
The European Broadcast Union and Advanced Media Workflow Association will unveil the new SOA Framework for Interoperability of Media Services (FIMS) in TV Production at IBC 2011 in Amsterdam next month.
The EBU did not want to repeat work already done and so decided to adopt a model for SOA first developed almost a decade ago by the IT industry standards body Oasis as the basis for its planned framework. Subsequently, the EBU then found that the Media Workflow Association (AMWA), which focuses on file-based workflows to benefit content creators including film, television, advertising, Internet and post-production professionals, was working along similar lines. The two bodies then joined forces to develop the Framework for Interoperability of Media Services (FIMS), which was announced at NAB 2011 in Las Vegas, but without details.
Now the EBU and AMWA are ready to unveil FIMS 1.0, which will be demonstrated at the EBU Village near the IBC conference centre during the exhibition. The demonstration will show typical media services including capture, transfer and transcoding, with exchange of media files wrapped in the OP1a MXF (Material Exchange Format) versioning format.
Files are displacing videotape and film in acquisition and delivery. This raises the question ‘if we begin with files, post produce files and deliver files, why do we need conventional post and broadcast products? Can’t commodity IT kit do the job?’
The need has never been greater to get costs under control. Increasingly, commodity IT products can do the job -- but there’s growing evidence that to really drive down costs, we have to stop simply dropping IT-based products into conventional post and broadcast architectures and really start to think about business processes. That’s why Service Oriented Architecture (SOA) is now a hot topic. SOA is not a technology but rather a design philosophy widely used outside our industry, write Bruce Devlin and Mark Horton of AmberFin.
At the recent IBC Show in Amsterdam, numerous vendors were extolling the benefits of a service oriented architecture (SOA) for capturing, producing, processing and distributing video and audio content as digital files. It’s the latest industry buzz term, but this one appears to have staying power as it brings the potential cost- and resource-saving benefits for both customers and the manufacturers themselves.
Although clearly interested, many attendees were left feeling a bit cautious about how to most effectively design and implement such an IT-centric system, even with the knowledge that it would increase efficiency and staff productivity while helping content providers manage the transition to a multi-screen, multi-format universe.
There are many options available for security and wading through the myriad of standards and security terms is not a trivial task. This blog will introduce some of the basic security concepts and describe different security techniques that can be applied in your domain.
One of the prerequisites for successful SOA implementations is service repository–a place to store and track changes of the existing Services portfolio.
I am not blogging much these days – most of it is due to trying to get my bloody book finished. A case study and a finished anti-pattern chapter where recently pushed to the MEAP, and here’s one additional pattern from chapter 6 (service consumer patterns):
When we try to think about service consumers, the obvious candidates are, of course, other services. Nevertheless there are other software components that interact with services e.g. legacy systems, Non-SOA external systems or reporting databases. The Composite Frontend pattern deals with yet another type of service consumer – the User interface.
First let just verify that User interfaces aren’t in fact services. One reason user interfaces are not services is that they converge several business areas e.g. if you want to enter an order you’d probably also want to lookup information about the customer, maybe you’d also want to browse the product catalog, look at open invoices etc. In addition to convergence, user interfaces deliver data rather than process it. User interfaces are data producers (actually there’s one exception to that – where the UI is the front of a “human service” see orchestrated choreography pattern (in chapter 7) for more details.
Ok, so UIs aren’t services, does it matter? Well, it does and the problem is not that UIs aren’t services per se. The main challenge caused by user interfaces comes from their main difference i.e. the aggregation or convergence of several services into a cohesive and useful UI.
Unlike most MEAPs on the market today, Convertigo offers a core technology platform that can instantly extract and process data from any enterprise data source or application. This means we can offer the following unique capabilities:
- No need to rewrite legacy and mainframe applications to fit your modern infrastructure – use them as is
- Instant access to any resource --whether or not there is an API
- You can combine any business logic for reuse across your enterprise
Cross-platform Mobile Development Features :
- Native support for all major mobile operating systems -- iOS, Android, BlackBerry
- The ability to use and leverage industry standard development tools and open source mobile frameworks -- Sencha, jQuery Mobile, and PhoneGap
- Support for SQL and web services including SOAP, REST and JSONPowerful server-based business logic assembly (and add yours as needed)
- Convertigo does not hold any business logic in the mobile application, which ensures reuse for different applications
Presentation done by Hiranya Jayathilake,Associate Technical Lead, WSO2 at the WSO2 Con 2011 : why an ESB is essential for SOA, what kind of problems it can solve and what it is not.
Service-Oriented Architecture (SOA) is a term that may seem tired and over-hyped today. However, it is WSO2’s case that SOA has always made perfect sense. It’s just that IT practitioners have often lost sight of its core principles in the noise and confusion of the market battle to sell SOA products. Our white paper, “Practical SOA for the Solution Architect”, is a retelling of the SOA philosophy in an easily understandable and practically applicable form, independent of the actual tools used to implement it.
Businesses are increasingly leveraging Cloud computing to drive opportunities and efficiencies in their day to day operations. In response to the growing use of smartphones and the advent of cloud-hosted services, enterprises are engaging in new and innovative ways with their customers, employees, partners and suppliers to increase brand loyalty, generate new revenues and improve the overall business experience.
The key to these advances is the Application Programming Interface (API). In a nutshell, APIs are the rules that determine how applications interface with cloud-side service offerings to enable enterprises to reach far beyond their own web properties to distribute data, content or services that have relevance to their business operations. Effectively these APIs are the interface to the business services and access to APIs is controlled by API keys. API keys are codes generated to control and manage access to these services and most organizations use some form of API keys to access their cloud services.
In this blog post we examine how Single Sign-On from the enterprise to Cloud-based services is enabled. Single Sign-On is a critical component for any organization wishing to leverage Cloud services. In fact, an organization accessing Cloud-based services without Single Sign-On risks increased exposure to security risks and the potential for increased IT Help Desk costs, as well the danger of “dangling” accounts from former employees which are open to rogue usage.
Let’s take a look at Google Apps and the concept of Single Sign-On. Organizations are increasingly using Cloud services such as Google Apps for email and document sharing. Google Apps, especially Gmail, are a popular option for organizations making their first foray into leveraging Cloud-based Services. While the cost advantages of this model are compelling, organizations do not want to create a whole new set of accounts for their employees in the Cloud, or force their employees to remember a new password.
The solution to this problem is to allow users to continue to use their own local accounts, logging into their computers as normal, but then seamlessly being logged into the Cloud services. In this way, the user experiences a continuous link from the corporate systems, such as their Windows login, into the Cloud services, such as email. This is known as Single Sign-On, and is enabled by technologies such as Security Assertion Markup Language (SAML).
The Apache CXF team is proud to announce the availability of the latest release of CXF: 2.5.0
This release contains several new features including a new Security Token Service, a new WS-Notification service, new security capabilities for JAX-RS services, enhanced OSGi support, enhanced WS-RM support, WS-MEX support, and more.
Currently in the media industry, users are implementing service-based systems using proprietary systems with bespoke software ‘glue’ holding it all together. They are doing this without an open, agreed framework and without standardized interfaces. While several organizations have identified a number of common processes such as capture which are performed essentially the same way throughout the industry, users are implementing these processes as services in different ways. At the same time, technology vendors are responding to demand for services-based products, but interoperability between different implementations is non-existent. This is because there is a lack of an agreed framework and publically developed service definitions in the media industry.
The AMWA-EBU FIMS (Framework for Interoperable Media Services) Task Force was established in December 2009. FIMS is a framework of service definitions for implementing media related operations using a Service-Oriented Architecture (SOA) approach. Media companies deploying this framework can expect that doing so will promote interoperability and reusability of services. FIMS defines service models with associated management, error handling, communication, and time awareness.
To properly exploit this technology the Task Force has developed a common framework which will help ensure integration interoperability, interchangeability and reusability of services. This will drastically reduce integration costs, allow users to more freely choose the most appropriate products on the market at any given time, improve maintainability, and aid in the adoption of new technologies.
FIMS also has begun the process of defining open services that are loosely coupled thereby enabling multivendor services to be integrated and creating “best-in-class” media systems. The services can span a wide domain of operations and permit integration of FIMS into business and management systems. The bottom line is that implementing FIMS will move facilities to an agile environment that is more easily configured, modified, managed and governed compared to non SOA systems.
“Conductor” plays a key role in Sony's new Tapeless initiative called Media Backbone. Based on a Service Orientated Architecture (SOA) Media Backbone enables heterogeneous platforms and applications to be easily integrated and managed via a common Enterprise Service Bus (ESB).
The benefits of an efficiently run, modular, scalable system are open-ended. A layered, abstracted system that can be viewed from a high level can be automated to an extreme degree, and integrated seamlessly with external services and consumers. Sony's experience with metadata-driven workflows is the key to integrating the proven benefits of SOA with a media production system.
Television news is, for a number of reasons, the most critical part of most broadcasters' operations. The way a broadcaster handles news is the clearest indication of its character, and the best way to create and manage a brand identity. Because of its very nature, it is a broadcaster's most complex operation, and working under intense pressure is an everyday norm.
There is a long history of technology solutions to ease the production of television news — dating back 30 years to first-generation newsroom computer systems such as Basys and Newstar. Newsroom computer systems have dealt traditionally with words: wire services, scripts, running orders and research archives.
More recently, a parallel stream of technology developed that handled the media assets: video clips, voice-overs and so on. The two computer networks are commonly linked, usually via a standard interface, which now is almost exclusively the Media Object Server (MOS) protocol. This production system manages ingest and live recording, moves content to editors and graphics workshops, compiles and delivers playlists, and hands completed content over to the archive.
These two systems are both mission-critical for the news broadcast. Both are complex and both have heavy demands on processing and network traffic. But, operating them as two independent, albeit linked, systems seems wrong. Instead, the ideal solution must be to have one computer network that handles all the elements of news production.
Put bluntly, such an architecture can be a nightmare to manage and maintain, and definitely not the path that should be taken in 2011. That said, let's look at a system that could very well be the answer broadcasters need.
While many architects believe that as an architectural style, REST is simpler and more straightforward that Web Services-based SOA, our research is turning up continued confusion over the principles of REST and how best to implement them. Everybody seems to get the basics—operate on resources at URIs with the four HTTP-centric operations GET, POST, PUT, and DELETE—but most people seem to miss the subtleties. Combine that confusion with the fact that you can do REST without SOA, the specifics of REST-based SOA are even more elusive, as we must pare down the essentials of both REST and SOA to understand the true nature of the combined approach.
How, therefore, should we handle Service abstractions, contracts, and compositions – arguably, the essence of SOA – in a REST-based SOA world?
The core idea of Compositional CRUD is to provide the basic CRUD operations not as discrete SOA services but as composable commands following the Command Pattern and the Promise Pipelining concept. This Jazoon Conference presentation shows how this approach has been implemented for managing complex price models at Credit Suisse Private Banking using the Eclipse Modeling Framework.
CRUD is a well-known approach for systematically deriving data access services from data models. While this approach is widely applied and easy to understand, it leads to several well-known limitations, especially in the context of service oriented architectures. Since only primitive data manipulation operations are made available, more complex operations require the sequential execution of these primitive operations. In typical SOA environments this has severe negative impacts on performance and, potentially, even consistency. To avoid these disadvantageous consequences, we’d like to introduce a refined approach, called Compositional CRUD.
Anyone working on enterprise systems in the last 10 years will remember the initial tenets of Service Orientated Architecture were to decouple applications and to provide a well defined service interface, which can be reused by applications and composed into business processes. The idea of reuse and composition made SOA an attractive proposition that sent thousands of organizations on a very challenging treasure hunt. We have since read SOA's obituary and its resurrection with many stories of woe peppered with some success, but with very few achieving the holy grail of SOA. Meanwhile, the web has essentially become a service oriented platform, where information and functionality is a available through an API; the Web succeeded where the enterprise largely failed.
This success can be attributed to the fact that the web has been decentralized in its approach and has adopted less stringent technologies to become service oriented. Many early APIs were written using SOAP but now REST is the dominant force (though some are more REST than others). The publication of REST APIs has been rapidly increasing.
Formula 1 has been the race all the racers are waiting for and it has become the worlds most attracted race.
ESB performance has been equally discussed, interesting topic in the IT industry. esbperformance.org and the performance test kit described by it has become the de-facto standard of the ESB performance testing.
This time, the round #5 shows that the UltraESB has been taking the lead on every front. The other 7 open source ESB's that is being tested are as follows : - WSO2 ESB
To get content containing either thought or leadership enter:
To get content containing both thought and leadership enter:
To get content containing the expression thought leadership enter:
You can enter several keywords and you can refine them whenever you want. Our suggestion engine uses more signals but entering a few keywords here will rapidly give you great content to curate.
Your new post is loading...
![Framework for Interoperable Media Services : FIMS White Paper [PDF] | SOA Breakthroughs | Scoop.it](https://img.scoop.it/3wbB31kLNiKwnOisLmJzRTl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9)
